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:
If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.
Before commenting, note:
This page is not for consensuspolling. 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.
Toward helping readers understand what Wiki is/isn’t
I’ve often noticed confusion on the part of both general readers and editors about what Wikipedia articles are AND aren’t. Truth be told, I suspect all of us editors probably had it not only before becoming editors but also well into our Wiki work.
So I got thinking that perhaps a cute (but not overly so!) little information box that would fly in or otherwise attract attention upon accessing a new article could help halt some common misunderstandings or lack of awareness of general readers. Because I think most editors here at the Pump would be aware of many such examples, I hope you’ll forgive my not providing e.g.’s.
(Of course if such an info box were put in place, there’d also need to be a way for readers not to see it again if they so wish.)
I started to check elsewhere at the Pump to see if a similar idea had ever been submitted before, but I couldn’t figure out a relevant search term. And I didn’t want to suggest an outright proposal if anything similar had in fact ever been proposed. So IDEA LAB just seemed a good place to start the ball rolling. Looking forward to seeing where it leads. Augnablik (talk) 10:58, 17 November 2024 (UTC)[reply]
I'm a strong supporter of providing more information about how Wikipedia works for readers, especially if it helps them get more comfortable with the idea of editing. Readers are editors and editors are readers—this line should be intentionally blurred. I don't know if a pop up or anything similar to that is the right way to go, but I do think there's something worth considering here. One thing I've floated before was an information panel featured prominently on the main page that briefly explains how every reader is an editor and gives some basic resources. Thebiguglyalien (talk) 17:49, 17 November 2024 (UTC)[reply]
The problem with putting stuff on the main page is that many (probably most) readers get to Wikipedia articles from a search engine, rather than via the main page. Phil Bridger (talk) 17:57, 17 November 2024 (UTC)[reply]
The main page gets 4 to 5 million page views each day. And even so, I would guess that people who go out of their way to read the main page are better candidates to become frequent editors than people who treat Wikipedia like it's part of Google. Thebiguglyalien (talk) 15:12, 18 November 2024 (UTC)[reply]
I wasn't thinking of the main page. What I had in mind was that whenever someone requests to go to an article — irrespective of how he or she entered Wikipedia — the information box would fly in or otherwise appear. Augnablik (talk) 17:30, 18 November 2024 (UTC)[reply]
@Khajidha, i don't see the box as ONLY to dispel confusion but ALSO to point out some strengths of Wikipedia that probably readers wouldn't have been aware of.
A few things that came to my mind: although Wikipedia is now one of the world's most consulted information sources, articles should be considered works in progress because ... however, there are stringent requirements for articles to be published, including the use of strong sources to back up information and seasoned editors to eagle-eye them; writing that is objective and transparent about any connection between writers and subjects of articles ... and (this last could be controversial but I think it would be helpful for readers in academia) although not all universities and academic circles accept Wiki articles as references, they can serve as excellent pointers toward other sources.
if the idea of presenting an information box including the above (and more) is adopted, a project team could work on exactly what it would say and look like. Augnablik (talk) 18:58, 18 November 2024 (UTC)[reply]
I think that considerably overstates reality (the requirements are not stringent, sources do not have to be strong, many things are not checked by anyone, much less by seasoned editors, hiding COIs is moderately common...).
Ooops. Well, if stringent requirements, etc., overstate reality, then official Wiki guidance and many Teahouse discussions are needlessly scaring many a fledgling editor! 😱 Augnablik (talk) 19:40, 18 November 2024 (UTC)[reply]
All of these points also fall into the "well, DUH!" category. I did, however, want to respond to your statement that "not all universities and academic circles accept Wiki articles as references". I would be very surprised if any university or serious academic project would accept Wikipedia as a reference. Tertiary sources like encyclopedias have always been considered inappropriate at that level, as far as I know. --User:Khajidha (talk) (contributions) 19:38, 18 November 2024 (UTC)[reply]
Point taken about encyclopedias being generally unacceptable in academic writing.
But as we’re having this discussion in an idea lab, this is the perfect place to toss the ball back to you, Khajidha, and ask how you would describe Wikipedia for new readers so they know how it can be advantageous and how it can’t?
As I see it, that sort of information is a real need for those who consult Wikipedia — just as customers appreciate quick summaries or reviews of products they’re considering purchasing — to get a better handle on “what’s in it for me.” Augnablik (talk) 20:05, 18 November 2024 (UTC)[reply]
I think the logo at the top left already does a pretty good job: "Wikipedia: The Free Encyclopedia". Especially if you look at the expanded form we use elsewhere: "Welcome to Wikipedia, the free encyclopedia that anyone can edit."--User:Khajidha (talk) (contributions) 12:39, 19 November 2024 (UTC)[reply]
@Khajidha, a mere tag saying "The Free Encyclopedia" seems to me just a start in the right direction. The addition of "that anyone can edit" adds a little more specificity, although you didn't mention anything about writing as well as editing. Still, I think these tags are too vague as far as what readers need more insight about.
I'm working on a list of things I'd like to bring to readers' attention, but I'd like to put it away tonight and finish tomorrow. At that point, I'll humbly request you to "de-DUH" your evaluation of my idea. Augnablik (talk) 17:01, 20 November 2024 (UTC)[reply]
Seems to me the problem is that people don't understand what an encyclopedia is. That's a "them" problem, not an "us" problem. And what exactly do these readers think editing the encyclopedia would be that doesn't incude writing it? User:Khajidha (talk) (contributions) 17:45, 20 November 2024 (UTC)[reply]
Wikipedia is very different from the historical concept of encyclopedia. The open editing expands the pool of editors, at the expense of accuracy. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)
Wikipedia may have put traditional general encyclopedias out of business, or at least made them change their business model drastically, but it does not define what an encyclopedia is. One example is that Wikipedia relies largely on secondary sources, but traditional encyclopedias, at least for the most important articles, employed subject matter experts who wrote largely on the basis of primary sources. It is our job to explain the difference. Phil Bridger (talk) 20:03, 20 November 2024 (UTC)[reply]
After a little longer gap between than what I thought it would take to create a list of things I believe all readers need to be aware of from the git-go about what Wikipedia is and isn't, due to some challenges in other departments of life, here's what I came up with. It would be in sections, similar to what you see below, each surrounded by a clip art loop, perhaps golden brown, and perhaps a few other pieces of clip art to set it off visually.I wish I knew how to separate paragraphs with line spacing ... I know this looks a little squished.
_____________________________________
New to reading Wikipedia articles? Here are some helpful things for you to be aware of about Wikipedia. They'll help you get more clearer ideas of how you can use the articles to best advantage.
If you'd like to go into more depth about all this, and more, just go to the article in Wikipedia about itself by typing WIKIPEDIA in the Wikipedia search field.
Wikipedia is a different kind of encyclopedia.
— Its articles can be written and edited by anyone.
— They’re supposed to be based completely on reliable outside sources.
— They can be updated at any time, thus allowing for quick corrections or additions if needed.
— Wikipedia is free.
That’s the main difference between Wikipedia and traditional encyclopedias.
BUT:
All encyclopedias serve as starting points where readers can find out about information — especially the main thinking about particular subjects — then follow up as they wish.
Students and researchers: keep in mind that schools and professional research journals don’t accept encyclopedias as references for written papers, but do encourage using them to get some ideas with which to go forward.
Wikipedia has become popular for good reason.
— Wikipedia is the world’s largest-ever encyclopedia.
— It’s consistently ranked among the ten websites people visit most.
— Because it’s all online, it’s easy to access.
— Because it’s highly interactive, it’s easy to move around from topic to topic.
Quality standards for writing articles are in place and in action behind the scenes.
— Wikipedia has high standards for choosing the subjects of articles.
— Wikipedia also has high standards for writing articles, especially freedom from bias.
— Certain editors are assigned to ensure that articles follow Wikipedia standards.
— Although differences of opinions naturally arise about whether a particular article does so, there are sets of procedures to work them out and arbiters to step in as needed. Augnablik (talk) 10:18, 25 November 2024 (UTC)[reply]
Why would you put information about "reading Wikipedia articles" in an editing environment?
Also, several things you've written are just wrong. Wikipedia is not considered a "highly interactive" website. "Certain editors" are not "assigned to ensure" anything. Wikipedia does not have "high standards for writing articles", and quite a lot of readers and editors think we're seriously failing in the "freedom from bias" problem. We might do okay-ish on some subjects (e.g., US political elections) but we do fairly poorly on other subjects (e.g., acknowledging the existence of any POV that isn't widely discussed in English-language sources). WhatamIdoing (talk) 20:14, 28 November 2024 (UTC)[reply]
Actually, I think a more magnetic format for this tool I'm hoping can one day be used on Wikipedia would be a short series of animated "fly-ins" rather than a static series of points with a loop around each set thereof. Augnablik (talk) 13:51, 25 November 2024 (UTC)[reply]
@Augnablik, personally, I think your idea would be great and would help bring new editors to the project, especially with these messages, which seem more focused on article maintenance (more important nowadays imo) than article creation.
Because I had such high hopes of being on the trail of something practical to help prevent some of the main misunderstandings with which readers come to Wikipedia — and at the same time to foster awareness of how to use it to better advantage — I wonder if a little spark could get the discussion going again. Or does the idea not seem worth pursuing further? Augnablik (talk) 11:05, 30 November 2024 (UTC)[reply]
I hope you won't be disheartened by this experience, and if you have any other good ideas will share them with us. There are two stages to getting an idea implemented in a volunteEr organisation:
Getting others to accept that it is a good idea.
Persuading someone to implement it.
You have got past stage 1 with me, and maybe others, but I'm afraid that, even if I knew how to implement it, it wouldn't be near the top of my list of priorities. Phil Bridger (talk) 09:17, 3 December 2024 (UTC)[reply]
Thank you, Phil. No, not disheartened … I think of it as an idea whose time has not yet come. I’m in full agreement about the two stages of idea implementation, plus a couple more in between to lead from one to the other.
When we in the creative fields recognize that continuum and get our egos out of the way, great things begin to happen. Mine is hopefully drying out on the line.😅 Augnablik (talk) 09:41, 3 December 2024 (UTC)[reply]
New users, lack of citation on significant expansion popup confirmation before publishing
There are many edits often made where a large amount of information is added without citations. For new users, wouldn't it be good if it was detected when they go to publish an edit lacking citations with a large amount of text, and came up with a popup of some sort directing them to WP:NOR, and asking them to confirm if they wish to make the edit? I think you should be able to then turn it off easily (as in ticking don't remind me again within the popup), but my impression is that many make edits without being familiar with the concept of rules such as WP:NOR. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 01:36, 19 November 2024 (UTC)[reply]
If I'm thinking of the right tool, there was a discussion (at one one of the village pumps I think) that saw significant opposition to deployment here, although I can't immediately find it. I seem to remember the opposition was a combination of errors and it being bundled with VE? I think Fram and WhatamIdoing were vocal in that discussion so may remember where it was (or alternatively what I'm mixing it up with). Thryduulf (talk) 15:21, 19 November 2024 (UTC)[reply]
@Aaron Liu, Edit check is available on the visual editor. Having it on wikitext won't make sense as the goal is to teach users to add citations, not to teach them both about citations and wikitext. Let's reduce complexity. :)
And the visual editor is still not the default editor at de.wp or en.wp. I advised to work on deploying both in parallel so that newcomers would have a better editing experience all at once (less wikitext, more guidance). Why am I not working on it now? Because it would take time. Now that the visual editor was used for years at all other wikis to make millions of edits, we should consider making it the default editor at English Wikipedia for new accounts. It could be a progressive deployment. I've not yet explored past reasons why English Wikipedia didn't wanted to have the visual editor being deployed, again for time reasons. But we would support any community initiative regarding VE deployment for sure.
We could deploy Edit check without VE, but I'm afraid of a low impact on newcomers: they are less likely to be helped as long as VE remains the second editor.
@Thryduulf, there were a discussion about Edit check in the past, you are correct. It covered multiple topics actually. I let you re-read it if you like; I didn't found "significant opposition" there, more questions about Edit Check, VE, citations and more, concerns on Edit Check and VE integration, and support for a better experience for newcomers (as long as it doesn't impact existing personal experiences).
If you didn't see "significant oppo sition" there, then perhaps reread it? The tool you deployed elsewhere had no measurable positive impact (when tested on Simple or French Wikipedia). As for past reasons why enwiki didn't want VE deployed, let's give you one: because when VE was deployed here, it was extremely buggy (as in, making most articles worse when used, not better), but the WMF refused to undo their installation here (despite previous assurances) and used enwiki as a testing ground, wasting tons of editor hours and creating lots of frustration and distrust towards the WMF. This was only strengthened by later issues (Flow, Gather, Wikidata short descriptions) which all followed the same pattern, although in those cases we eventually, after lots of acrimonious debates and broken WMF promises, succeeded in getting them shut down). As shown in the linked discussion, here again we have two instances of WMF deployments supported by test results where in the first instance reality showed that these were probably fabricated or completely misunderstood, as in reality the results were disastrous; and in the second instance, Edit Check, reality showed that the tool wasn't an improvement over the current situation, but even when spelled out this was "misread" by the WMF. Please stop it. Fram (talk) 15:50, 19 November 2024 (UTC)[reply]
Could you provide a couple of links to comments from people other than yourself, and which specifically opposed EditCheck (not the 'make the visual editor the default' or 'Citoid has some problems' sub-threads)? I just skimmed through the 81 comments from 19 editors in the proposal that Robertsky made, and while I might have missed something, your first comment, which was the 69th comment in the list, was the first one to oppose the idea of using software to recommend that new editors add more citations.
Most of the discussion is not about EditCheck or encouraging refs. Most of it is about whether first-time editors should be put straight into the visual editor vs asking them to choose. The responses there begin this way:
"I thought Visual Editor is already the default for new accounts and unregistered editors?" [1]
"In theory, this sounds like a great idea. I'm eager to try it out..." [2]
"I'd support making Visual Editor the default..." [3]
"I totally agree that VE should be the default for new users." [5]
which is mostly not about whether to use software to encourage newbies to add more citations (the second quotation is directly about EditCheck; not quoted are comments, including mine, about whether it's technically necessary to make the visual editor 'the default' before deploying EditCheck [answer: no]).
Then the thread shifts to @Chipmunkdavis wanting the citation templates to have "an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first", which is about how the English Wikipedia chooses to organize its CS1 templates, and @Thryduulf wanting automatic ref names that are "human-friendly" (to take the wording RoySmith used), both of which entirely unrelated to whether to use software to encourage new editors to add more citations.
I see some opposition to putting new editors into the visual editor, and I see lots of complaints about automated refs, but I don't see any opposition from anyone except you to EditCheck itself. Please provide a couple of examples, so I can see what I missed? WhatamIdoing (talk) 17:57, 19 November 2024 (UTC)[reply]
"which is about how the English Wikipedia chooses to organize its CS1 templates" is perhaps one way to say that the VE has no functionality to accept the synonyms, which I discovered in a few disparate conversations following that thread. I still have a tab open to remind me to put a note about phab on this, it's really not ideal have VE editors shackled with the inability to properly record author names. CMD (talk) 01:42, 20 November 2024 (UTC)[reply]
VisualEditor is perfectly capable of accepting actual aliases such as |author=, and even non-existent parameters such as |fljstu249= if you want (though I believe the citation templates, unlike most templates, will emit error messages for unknown parameters). It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so. WhatamIdoing (talk) 05:12, 20 November 2024 (UTC)[reply]
If you know how to solve the problem, please solve the problem. Per Help talk:Citation Style 1/Archive 95, "The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData". As it stands, VE doesn't do it, and I've seen no indication that they consider it an issue. CMD (talk) 12:00, 20 November 2024 (UTC)[reply]
If you want this wikitext:
{{cite news |author=Alice Expert |date=November 20, 2024 |title=This is the title of my news story |work=The Daily Whatever}}
which will produce this citation:
Alice Expert (November 20, 2024). "This is the title of my news story". The Daily Whatever.
then (a) I just did that in the Reply tool's visual mode, so it obviously can be done without any further coding in MediaWiki, VisualEditor, or anything else, and (b) you need to convince editors that they want "Alice Expert" at the start instead of "Expert, Alice" of citations. WhatamIdoing (talk) 21:07, 20 November 2024 (UTC)[reply]
No, I don't have to convince editors that they want "Alice Expert" instead of "Expert, Alice". The issue is, as covered in the original discussion with some good input from others, non-western name formats. It is a cultural blindspot to assume all names fall into "Expert, Alice" configurations, and it seems that it is a blindspot perpetuated by the current VE expectations. CMD (talk) 01:39, 21 November 2024 (UTC)[reply]
@Chipmunkdavis, I guess I'm having trouble understanding what you want.
You said in the linked discussion that "My understanding is that the VE tool does not allow for the use of aliases". I'm telling you: Your understanding is wrong. It's obviously possible to get |author= in the visual editor, because I did that. Either this diff is a lie, or your understanding is mistaken. I'm going with the latter. |author=Mononym is already possible. So what change are you actually asking for?
The linked discussion seems, to my eyes, to be a long list of people telling you that if you don't like the description used in the TemplateData (NB: not MediaWiki and not VisualEditor), then you should change the description in the TemplateData (NB: not MediaWiki and not VisualEditor) yourself. You say the devs told you that, and I count at least two other tech-savvy editors who told you to WP:SOFIXIT already. Neither the part that says "Last name" nor the part that says "The surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors" is part of either the visual editor or MediaWiki. Any editor who can edit Template:Cite news/doc can change those words to anything they want. WhatamIdoing (talk) 20:22, 21 November 2024 (UTC)[reply]
Having to type source wikitext completely defeats the purpose of the visual editor; why not just type in the wikitext editor. This "solution" is a blaring technicality.Perhaps you should read the last four replies in the linked discussion. Aaron Liu (talk) 00:00, 22 November 2024 (UTC)[reply]
Right, this is the sort of odd reply this topic inexplicably gets. You can just type in source code in the visual editor, I mean, why have visual editor at all. Just change the description so people can pretend someone's name is their last name, now being suggested yet again as a simple SOFIXIT, and no I'm not going to deliberately and formally codify that we should mislabel people's names, for what I did think before these various discussions were obvious reasons. CMD (talk) 02:08, 22 November 2024 (UTC)[reply]
If I type |author=Sting vs |last=Sting, will this make any difference to anyone (human or machine) that ►is not looking at the wikitext. That last bit about not seeing the wikitext is the most important part. If the complaint is entirely about what's in the wikitext, then Wikipedia editors should treat it as the equivalent of a whitespacing 'problem': it's okay to clean it up to your preferred style if you're otherwise doing something useful, but it's not okay to force your preferred style on others just for the sake of having it be 'the right way'.
The options are:
Those two are used as exact synonyms by the CS1 code, in which case it make no practical difference which alias is used, or
Those two are handled differently by the CS1 code (e.g. emitting different microformatting information), in which case the CS1 code should not declare them to be aliases. AIUI aliases are only supposed to be used for exact substitutes.
Misnaming someone is not a style choice. (It is literally an item explicitly mentioned in the UCOC.) Even if it wasn't, your professed solution is that a new editor open up the visual editor and see "Last name: The surname of the author; don't wikilink, use 'author-link' instead; can suffix with a numeral to add additional authors. Please also use this field for names which don't have a first name last name structure."? That doesn't seem sensible or effective. CMD (talk) 00:12, 29 November 2024 (UTC)[reply]
Where does the "misnaming" happen? To be clear, I'm expecting an answer that either sounds like one of these two:
"Only in the wikitext, but that's still very bad".
"In a reader/user-facing location, namely _____" (where the blank might be filled in with something like "in the COinS microformatting").
I would refer to the previous discussions above and elsewhere where it has already been extensively covered that both of those options are true. It would in the wikitext, and is currently in the visual editor citation creator. CMD (talk) 08:34, 30 November 2024 (UTC)[reply]
"Both of those options are true" is not possible, when you name as the two locations:
a place readersdo not see ("in the wikitext") and
another place readers do not see ("in the visual editor citation creator").
It feels deeply uncivil to say "So again" for a question you haven't asked before. It is really surprising to see "misnaming" quoted as if it's something incorrect; it's hard to word this but that comes off as a shocking level of continued cultural insensitivity. At this point the various questions at hand have been answered multiple times in the different discussions, and we're wandering again towards odd red herrings that have little relation to the fact that VE source generator users are forced into a single naming system, something long solved by the non-VE source generator. I recommend the link RoySmith provided in the previous discussions if you haven't already[6], and remain hopeful one day that others will try to care about the non Alice Experts of the world. CMD (talk) 02:13, 1 December 2024 (UTC)[reply]
Sorry, I thought I had already been quite clear about that point:
This is coming off as deliberately obtuse. The issue is for the person using the visual editor, the new editors we are trying to cultivate. CMD (talk) 15:58, 13 December 2024 (UTC)[reply]
People using the visual editor's template editor never see |last= on the CS1 templates. That is only visible to people using wikitext.
People using the visual editor's template editing tools see the locally defined TemplateData label "Last name", which CMD is free to change at any time to anything he can get consensus for, e.g., "Last name, sole name, or non-Western style name". WhatamIdoing (talk) 00:44, 4 December 2024 (UTC)[reply]
So we want text that is defined in TemplateData to say something different, but the method of changing that must not involve changing the text that is defined in TemplateData.
It's an eminently solvable problem, the radio button idea has already been raised. Just takes a bit of actually thinking getting people's name's right is an issue, and not changing the actual question at hand. CMD (talk) 15:57, 13 December 2024 (UTC)[reply]
1. How did you do that? 2. The author parameter is useful and used iff the author has no last name; e.g., byline being an organization, mononymous person, no author stated, etc. This is documented at the citation-style help pages. Aaron Liu (talk) 22:11, 20 November 2024 (UTC)[reply]
The |author= parameter behaves the same as the |last= parameter, so there's little point in changing the wikitext to say |author=.
(In this case, I took the quick and dirty approach of typing out the template by hand, and pasting it in. The Reply tool's visual mode normally won't let you insert a template at all, because block-formatted templates completely screw up the discussion format. Normally, if there's no TemplateData to provide you with the options, then you'd click on the "+Add undocumented parameter" button and type in whatever you wanted. If there is TemplateData, then see my earlier comment that "It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so.") WhatamIdoing (talk) 23:08, 20 November 2024 (UTC)[reply]
It's semantically different, like the em tag vs italicizing and whatnot. And as I've said before, the documentation doesn't suggest it so that the clueless will not use both |last and |author. Aaron Liu (talk) 23:57, 20 November 2024 (UTC)[reply]
If someone adds |authorn= as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement.
You missed that none of them tested it or checked it on other wikipedia versions, and that no support came along after I had tested it and posted my results? No surprise here... Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
There's a big gap between "The discussion stopped" and "There was significant opposition in this discussion".
In terms of EditCheck, I found most of the discussion to be off-topic, but I can honestly only find one editor (you) who opposed it in that discussion. I assume your failure to provide links to any other statement of opposition means you also honestly can't find a single comment in that discussion from anyone who agreed with you – just an absence of further comments, and an unprovable assumption on your part that its due to everyone agreeing with you. WhatamIdoing (talk) 19:28, 19 November 2024 (UTC)[reply]
Didn't stop you from making any assumptions or presentings things in the most WMF-favorable light. Seems like VE all over again, only then you had the excuse of being paid by the WMF. Fram (talk) 19:45, 19 November 2024 (UTC)[reply]
I don't think I presented the discussion in the most WMF-favorable light. The discussion started off pretty enthusiastic, but it was mostly enthusiastic about something other than EditCheck itself. It then turned into a long digression into something completely unrelated.
(My own contributions to that discussion were technical in nature: It doesn't require the visual editor as the default; code may already exist for an unrelated change that someone wants; stats may already exist for something close to the numbers someone else wants.) WhatamIdoing (talk) 19:56, 19 November 2024 (UTC)[reply]
(ec) Fram, this is precisely because I reread the conversation that I wrote my previous message. We have the right to disagree, but it should remain civil and not convey accusations of bad faith. The way you try to depict me as a dishonest person is not acceptable at all.
I let other participants have a look at the previous discussion we linked, also take a look at the data we provided, and make their own opinion. We aren't the two people who will decide of a deployment here: I'm just the messenger, and you are not the person who has the final word on behalf of everyone. Trizek_(WMF) (talk) 18:00, 19 November 2024 (UTC)[reply]
Tough luck. You posted a dishonest reply last time we had this discussion. If it had been a genuine error in that previous discussion, you should have just said so. Instead, you not only let your error stand, but then come here and claim that there was no significant opposition to Edit Check in that previous discussion, ignoring the one person who tested it and posted results. And like I said in that discussion, the data the WMF provides is not to be trusted at all, as seen from other deployments. Which I already stated and you again ignore completely. But, like I said, the WMF (and previous WMF employees like Whatamidoing) are very good at civil bullshit, while I am not so good at the civil part but rather good at cutting through the bullshit. Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
Since there are non-native English speakers in this discussion, I'd like to clarify that "dishonest", in English, means that the person deliberately told the opposite of the truth. For example, it is dishonest to say "I love Windows ME", when you actually hate it.
However:
Having incorrect or outdated information is not "dishonest".
Caring about a particular benefit more than a different problem is not "dishonest".
Disagreeing with you, or with a hypothetical average reasonable person, is not "dishonest".
There's a reason that English has an idiom about an "honest mistake": It's because it's possible to be factually wrong without being dishonest. For example, if you say "Oh, User:Example said something yesterday", but upon further inspection, it was a different user, or a different day. Or even if you say "The previous discussion shows significant opposition to EditCheck", but upon further inspection, nobody except you publicly opposed it. Such a sentence is only dishonest if the speaker believes, at the time of speaking, that the statement is factually wrong. Unless the speaker believes themselves to be speaking falsehoods, it's not actually dishonest; it's only a mistake or an error.
"Using someone's affiliations as an ad hominem means of dismissing or discrediting their views" – Claiming, or even implying, that WMF staff have a tendency to be dishonest is probably a violation of this point in the policy.
"Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done." – Claiming that anyone is "dishonest", especially when the difference between your view and theirs is a matter of opinion, is very likely a violation of this policy. It doesn't officially matter if the manner in which you say this is "you are dishonest" or "your replies are dishonest"; it's still insulting and disparaging another editor.
Like I said, one can post all distruths one wants as long as one does it civilly. Reminds me of the discussions we had about VE when it was disastrously deployed but all you did as a liaison was defend the WMF no matter what. And I didn't say their replies were dishonest because they are a WMF employee, just that it is typical behaviour for many of them apparently. Perhaps reread the breakdown of the Gather discussions I gave below, or reread the countless discussions about Flow, VE, descriptions, ... There are some good apples among them, but not too many. Fram (talk) 19:51, 19 November 2024 (UTC)[reply]
2013, not 2023. July was early days in VE testing, when I still thought you were helpful. A few months later I had become wiser. Fram (talk) 20:20, 19 November 2024 (UTC)[reply]
For what its worth, I do think a RfC can be made once the proposed details of the deployment is firmed up:
Do we make VE as the default for new editors?
Do we enable EditCheck as it is?
Current pop-up for new editorsAside, if we retain the current arrangement, i.e. letting new/anon editors selecting their preferred editor, can we change the buttons to be more balanced in colours and sizing? These do affect one's preference in choosing which button to click. – robertsky (talk) 18:16, 19 November 2024 (UTC)[reply]
robertsky, that's two RFCs, and – respectfully – conflating the two questions was a primary contributor to how far off the rails this conversation got last time.The UX alterations are probably best brought up at meta or mw for the skins devs to consider. Folly Mox (talk) 18:55, 19 November 2024 (UTC)[reply]
Gather was dropped after 3 months (without any "broken WMF promises" nor any time for them to have given such promises or to have acrimoniously debated), and Wikidata SDs seem to be deployed and working completely fine. Aaron Liu (talk) 18:25, 19 November 2024 (UTC)[reply]
Gather was deployed in March 2015 and immediately got severe backlash at the announcement: Wikipedia:Administrators' noticeboard/Archive270#Extension:Gather launching on beta. No good answers followed. So three weeks later we get Wikipedia:Administrators' noticeboard/Archive270#Moderation of Collections?, where we get (laughable) promises of what the WMF will do to solve some of the most basic problems of this tool they rolled out on enwiki but hadn't really thought about at all it seems. Instead, they created a new Flow page on enwiki for this tool (Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback) despite Flow being removed from enwiki long before this. So in January 2016 (hey, that's already 10 months, not 3), Wikipedia:Village pump (proposals)/Archive 130#Disabling Gather? was started. On 22 Januuary 2016, an answer was promised by the WMF "next week" (section "A WMF reply next week"): "by next week, the Gather team will have a major update to share about the feature". Things escalated, so another WMF person came along 6 days later to promise "we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after." (section "A Response from the WMF"). So instead of some great announcement after 1 week, we are now 6 days further and will get big news 2 weeks later... So, more than 2 weeks later, 12 February, we get "the analysis has taken longer than I anticipated. I'll post the results as soon as I can." So, on the 19th, they posted a "proposal" to which others replied "that proposal is an insult to the community." and "his smacks of yet more stalling tactics and an attempt to save face". Only when the RfC was closed with truly overwhelming supprt to disable it did they finally relent.
Do you really need a similar runthrough of Wikidata short descriptions, which are (or should be) disabled everywhere on enwiki and replaced by local descriptions instead? Or will you admit that perhaps you didn't remember details correctly? Fram (talk) 19:41, 19 November 2024 (UTC)[reply]
Yeah man I don't remember anything well, I wasn't there. I'm just reading random things I can find to see what you're talking about, such as the MediaWiki page that states development was suspended by July 2015, but as you've pointed out, that is different from disabling, and thank you for helping me to find. Thanks for your links on Gather. By no fault of its own, Shortdesc helper made me conflate WD descriptions and SDs. Aaron Liu (talk) 20:42, 19 November 2024 (UTC)[reply]
I never suggested deploying it on the source editor. Having not fully read the above discussion yet, it currently seems unreasonable that it's not deployed in the visual editor on enwiki and dewiki (while preserving the current "level of defaultness" of the visual editor itself instead of increasing the defaultness). Aaron Liu (talk) 16:30, 19 November 2024 (UTC)[reply]
@Aaron Liu, I never implied you suggested it, I was just one step ahead telling you that it is not available on source editor. :) We can deploy Edit check without changing the "level of defaultness" of the visual editor itself, but the impact might not be the same. Trizek_(WMF) (talk) 18:09, 19 November 2024 (UTC)[reply]
(ec) Probably Wikipedia:Village pump (proposals)/Archive_213#Deploying_Edit Check on this wiki. Having reread that thread, it combines all WMF rollout issues into one it seems, from starting with false requirements over a testing environment which isn't up-to-date at all to completely misreading everything that is said into something supposedly positive, ignoring the stuff that contradicts their "this must be pushed no matter what" view. But all in a very civil way, there's that I suppose... Fram (talk) 15:39, 19 November 2024 (UTC)[reply]
What an utterly weird objective for that tool "Newcomers and Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing to publish changes they are proud of and that experienced volunteers consider useful." Very neocolonial. Fram (talk) 15:25, 19 November 2024 (UTC)[reply]
Different parts of the world have different responses to UX changes. A change that is encouraging in a high-resource setting (or an individualistic culture, or various other things) may be discouraging in others. It is therefore important to test different regions separately. The Editing team, with the strong encouragement of several affiliates, decided to test sub-Saharan Africa first. WhatamIdoing (talk) 19:50, 19 November 2024 (UTC)[reply]
I can't help it if you don't see how insulting and patronizing it is to write "Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing". Fram (talk) 20:26, 19 November 2024 (UTC)[reply]
Redone my check at Simple wiki, looking at the most recent edits which automatically triggered this tool[7]. 39 instances were automatically indicated as "declined", the other 11 contain 3 edits which don't add a reference anyway[8][9][10] and 6 edits which actually add a reference[11][12][13][14][15][16] (though 3 of these 6 are fandom, youtube and enwiki). And then there is this and this, which technically add a source as well I suppose... Still, 3 probably good ones, 3 probably good faith bad ones, 3 false positives, and 2 vandal ref additions. Amazingly, this is almost the exact same result as during the previous discussion[17]. Fram (talk) 16:21, 19 November 2024 (UTC)[reply]
I think just creating one good source addition is enough cause for deployment (without making VE the default editor), especially since it doesn't appear to be causing additional harm. Aaron Liu (talk) 16:59, 19 November 2024 (UTC)[reply]
If it doesn't create more good source additions than we had before the tool, then there is no reason to deploy something which adds a popup which people usually don't use anyway. Without the popup, there also were new editors adding sources, it's not as if we came from zero. No benefit + additional "noise" for new editors => additional harm. Fram (talk) 17:10, 19 November 2024 (UTC)[reply]
I'm not sure what that has to do with my reply. Fram was disputing that the source additions were good and useful, and I was replying to him that some of them were good, hence edit check should be deployed (plus I'm fairly sure there's another check in the works to check reference URLs against the local RSP) Aaron Liu (talk) 18:21, 19 November 2024 (UTC)[reply]
What you observed (Editors who got a popup did not originally give a source when attempting to publish) is shown in the data we shared.
We already deployed checks to verify if a link added is not listed in rejection lists and make it more actionable by newcomers. Some users at other wikis expressed a need to have a list of accepted links (the ones that match RSP), but other said that it could prevent new good sources from being added. Thoughts?
Isn't that the programmed heuristic for when the popup appears? I don't get what this has to do with any stats.Only URLs in the spamlist are blocked. Edit check should strongly warn against adding sources found generally unreliable by consensus summarized at RSP. Aaron Liu (talk) 18:59, 19 November 2024 (UTC)[reply]
I'm not sure to understand, sorry. Stats are about users adding a citation when asked compared from where not asked. It is not connected to RSP.
Like I said, of the 11 supposed additions, 5 need reverting (as far as the source goes) and 3 didn't add a source. I don't trust WMF numbers at all, but 5/8 needing a revert is hardly an overwhelming success. Even assuming that the 3 good ones wouldn't have added a source otherwise, one then has to make the same conclusion for the others, and the 5 bad ones wouldn't have been included otherwise either. So where is the net benefit and the no harm? Fram (talk) 19:54, 19 November 2024 (UTC)[reply]
I don't trust WMF numbers at all
I'm new to all this, could you elaborate on why?
the 5 bad ones wouldn't have been included otherwise either
The 5 bad ones would have included no source at all if Edit Check wasn't there. I don't see how adding a blatantly terrible source is worse than adding text without a source at all. Both are checked the exact same way: eye-scanning. So there you go, net benefit and no harm. Aaron Liu (talk) 20:11, 19 November 2024 (UTC)[reply]
No. I explained it already in the previous discussion. You have made false claims about Gather and so on, but can't be bothered to reply when I take the time to give a detailed answer; but now you are apparently "new to all this" suddenly and want me to again take some time to enlighten you. No. And an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious. Fram (talk) 20:24, 19 November 2024 (UTC)[reply]
@Aaron Liu, I think this is a "reasonable people can disagree" thing. Some RecentChanges patrollers just revert any new unsourced claim, so if it's unsourced, it's quick to get out of the queue. Faster reverting means success to them, whereas encouraging people to add sources is like whispering a reminder to someone during a game of Mother, May I?: It removes an easy 'win' for the reverter.
OTOH, having a source attached to bad information has other advantages. It's easy to determine whether it's a copyvio if you have the source, and if you're looking at an article you know something about (e.g., your own watchlist rather than the flood in Special:RecentChanges), then having the source often means that you can evaluate it that much faster ("This is a superficially plausible claim, but I wouldn't trust that website if it said the Sun usually rises in the East").
For content that shouldn't be reverted, then IMO encouraging a source is always a good thing. For content that should be reverted, there are tradeoffs. WhatamIdoing (talk) 21:22, 19 November 2024 (UTC)[reply]
I miss things, especially on a workday. Sorry about that. I think the mobile short-descriptions thing is believable, as users . This is a case of the methodology being technically correct but misleading, which I don't see for the edit check study, unless you're willing to provide an argument.
an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious.
IMO, only slightly. Often, only users of experience patrol pages when reading them. (The unacquainted are also sometimes able to realize something's probably wrong with a swath of unsourced text, hence they make up part of the aforementioned "slightly".) And blatantly bad sources jump out to those experienced from the references section. Sources in the middle ground can often link to good sources, though there is a debate on how good it is to have both additionally middle-ground and bad sources vs. no sources at all. Personally, I think it's better. Aaron Liu (talk) 21:47, 19 November 2024 (UTC)[reply]
Given that there are several editors here interested in the feature turning on, I would like to propose the following question and a brief/neutral backgrounder to be asked for the RfC:
Background: Edit Check is Wikimedia Foundation's product to encourage new editors to add citations to their edits, by prompting them with pop-ups before publishing. The pop-ups will work under the following default conditions (points 2 - 4 can be configured further):
If editing is done through Visual Editor.
≥40 consecutive characters added.
All accounts with < 100 edits
All sections*
For point 4, I also propose to modify the configuration to exclude this feature from the following sections:
lead section, as we don't not require leads to have citations
Notes section, usually handled by {{efn}} in content body, etc.
References section, no citation required
External links section, no citation required
See also section, no citation required
Further reading section, no citation required (thanks, Chipmunkdavis)
And any other sections (that I have missed out, and in the future) that do not require citations.
For future changes of the configuration setting, this can be done on wiki through modifying MediaWiki:Editcheck-config.json file after discussing in an appropriate venue. This also means that other than the initial activation, we do not require further changes in the backend (and if we would want to rollback before deactivating in a server update, we can set the max edit count to 1 as a temporary measure).
@Robertsky, all is correct. Also, at the moment, Edit check has not been integrated to Community Configuration but, as you mention, the json file attached to Edit check allows your community to decide on de/activation. Trizek_(WMF) (talk) 09:11, 2 December 2024 (UTC)[reply]
Further reading section. Idly thinking, is the 100 edits namespace configurable? Further, just to check, "≥40 consecutive characters added." means "≥40 consecutive characters added without a ref tag" or similar? CMD (talk) 09:24, 2 December 2024 (UTC)[reply]
The 100 edits is not namespace configurable. From the codes, it is checked against wgUserEditCount JavaScript variable. There is no JavaScript variable(s) for breakdown of edit counts by namespace at the moment, going by this documentation.
{{Infobox officeholder}} already has a parameter for "Other political affiliations", which might be what you are looking for. Otherwise, yes, a section in the article text can be written if there are enough sources to position the person on the political spectrum, but there shouldn't be a strict guideline mandating it to be present, especially since these affiliations can be controversial or contested. Chaotic Enby (talk · contribs) 12:02, 24 November 2024 (UTC)[reply]
There are also many politicians whose views do not neatly fit into a simple left-centre-right box, especially as right-of-centre UK politics is roughly equivalent to the left wing of mainstream US politics. Thryduulf (talk) 00:49, 5 December 2024 (UTC)[reply]
Dead pixels, an expansion to WP:CITEWATCH, a new noticeboard?
Bit of a long one... more of an essay at this point really, but IMO, it might be worth it to prevent editor burnout and bring in new users, so here goes: You know how once one spots a dead pixel, they can't seem to ignore it? Then one starts wondering whether the monitor vendor has either: gotten sloppy with their work... or if they just got unlucky given the volume of monitors that get put out by the vendor. Then the dread of calling the warranty department...
Just like the analogy above, the news and research outputted by reliable sources is generally problem free. But because of the volume of information, occasionally errors will get in. Sometimes even unscrupulous outlets gets in. But unless one is motivated or knowledgeable enough, few will go through the effort of comparing what the reference says to its references (reference-in-reference). This is the dead pixel problem I'm talking about, and just like a dead pixel, annoys the crap of the person who sees it, for better or worse. Then comes the process of "fixing" it: currently, original research issues, and reference-in-reference issues are handled in science by PubPeer, whose extension is used by a paltry number of users. Response times by authors take days, maybe years even with relentless journalism. At any rate, most people who feel compelled to edit Wikipedia due to accuracy problems have probably never heard of PubPeer. And as for issues with regular journalists, I suppose one could turn to opinions by third parties like NewsGuard? And meanwhile, they can usually get away with publishing contradictory health news without being called out for it.
All made more worrying given that impact Wikipedia has on the real-world non-Wikipedians, like judges and scientists. Recent political developments, as well as LLM usage (see WP:CNET), mean that once reliable sources could suddenly hallucinate or contradict other sources on a whim. Maybe the errors made daily won't be indicative of LLM usage... but they could. In any case, we don't currently track these issues, so whose to say what patterns unreliable sources follow?
Mistake or no mistake, when the inaccuracy is inevitably spotted (probably by us, I wonder why...), an attempt will probably be made to re-balance the article or add footnotes following WP:Inaccuracy. This works great... if you are the only editor of a given article. For everyone else, because not everyone will necessarily see a dead pixel as a big deal, the actions may seem disproportionate and/or violate certain consensus policies, and the talk page will go on and on, maybe then to WP:DRN driving away casual but knowledgeable editors, all of which will be seen by hardly anyone, let alone the original author of the source. One could then go to WP:RSN, but that noticeboard is really only equipped to handle the most problematic and fringe sources, not really the daily errors that get published by sources day to day. We burn out, and the world, by and large, hardly notices the dispute.
To solve this, I propose some sort of objective-ish tracking in WP:CITEWATCH of reference-in-reference accuracy (in line with Wikipedia's policy of WP:NOR) as well as other issues like typos, linking issues, cotogenesis, copyright violations, notable omissions, and most importantly, corrections (sure sign of a RS), and the time elapsed from error spotting to correction for refs, all heuristics that, when aggregated, could be indicative of a sloppy copyeditors or cursory peer review. Editors could put in a template with the relevant issue, hidden by default until patrolled. If there is a dispute, a new reference-in-reference noticeboard, split into categories (typos, copyright violations, etc.)
Bonus benefits - we might finally:
Know which MDPI journals have decent peer review, allowing them to build a reputation?
Create an easy place to show that the consensus on WP:ALJAZEERA is justified?
Create an incentive to keep more accountable (especially on health related topics)? As well as obscure sources on obscure topics that may only be read by the Wikipedian.
Reduce biting and attrition by creating an easy place for sub-WP:RSN issues to be reported, counted and easily exportable to PubPeer or elsewhere?
Problematically high counts could then easily be reported to WP:RSN without the need for extensive, hard-to-read discussion.
Other references
External videos
No, Sabine, Science is Not Failing, Somewhat related video by Professor Dave that was coincidentally published while I was thinking about this. Mentions PubPeer. See also WP:WTW.
Older pre-internet sources might be less affected by ref-in-ref errors, since the reader could be reasonably expected to check the sources, necessity.
WVhere ref-in-ref notices go to the reader: Probably inside ref tags, after the chosen citation template?
This proposal could involve multiple changes to various guideline pages. WP:Inaccuracy will probably be changed the most by this proposal.
Patrolling - Mostly in anticipation of misunderstanding of policy, and WP:NOR.
Noiceboard name - RRN, reference-in-reference noticeboard? To avoid flooding the noticeboard, require discussion on talk page first? Split noticeboard into categories?
Categories - Categories will be separated into errors that will be reported to readers when patrolled, and those that will just be tracked by an expanded SOURCEWATCH table, for later discussion on RSN.
General typos - just track, probably a mistake, and shouldn't happen often with vigilant peer reviewers.
Ref-in-ref notable omission - Things like not disclosing a certain ref-in-ref is a preprint, failed, etc. Probably should report to the reader.
Ref-in-ref typo - Linking to the wrong paper in the paper's references. This should be reported to to the reader.
Ref-in-ref contradiction - Errors in copying data from another paper to the paper, making statements that are not supported by the other paper. I feel like this should be reported, like other the other Ref-in-ref categories
Copyright violation/plagiarism - Ref should be removed as soon as possible. If not, report, provide copyvio report.
Verifably illogical - Claims such as "birds don't exist" or "FDR invented the Federal Register" that would require overlooking enough sources to be problematic. This is mostly a catch-all category, for LLM hallucinations or otherwise, that should be used with caution, and should probably just be tracked.
Citogenesis/Citing Wikipedia - Apparently it's still a thing, but I'd prefer sources be honest rather than hide it (see [20][21]). Policies should encourage the use of permalinks to properly cite Wikipedia. Speaking of perverse incentives...
Perverse incentives? Less citing of sources overall? Counterpoints: Existing incentives to cite to increase impact or whatever. Could be solved with another category:
General contradiction - Tracking only, focus only on all refs that were ever cited on Wikipedia to reduce scope. Some contradictions are expected, but an excessive number of contradiction notes - more likely to be fringe?
Rolling this out might take an extended period of time, and will probably involve the WMF as well as new templates, modules, instructions, etc. Thoughts on this, as well as how improvements could be broken up or rolled out? ⸺(Random)staplers03:56, 25 November 2024 (UTC)[reply]
I must be tired I think, but I do not think I understood anything at all about the idea, whether it is the how or the why. The entire way the reliability of sources is approached is that no matter how trusted they are, no publication ever gets a blank check on any subject, and to me it does not seem like there is an issue of under-reporting perceived inaccuracies or bias either, so I am not sure I see the point. Choucas Bleutalkcontribs12:51, 5 December 2024 (UTC)[reply]
This is the English language Wikipedia and so there's already a template for the English version of this: {{LORD}}, which displays as LORD, as per the KJV. Andrew🐉(talk) 17:57, 3 December 2024 (UTC)[reply]
That template generates the English translation of the substitution אֲדֹנָי (Adonai transl. my Lord[s]), not the actual Tetragrammaton. There are multiple places in wiki where the actual Tetragrammaton is given, and it would be convenient if there were a template to save typing. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:58, 3 December 2024 (UTC)[reply]
New main page section: Wikipedia tips
I think a page informing the readers of Wikipedia features would be helpful, since the public largely do not know much about Wikipedia's backend even though billions visit this site. Topics featured can be looking a page history, talk page discussions, WP:Who Wrote That?, etc. I imagine it woule be placed under the Today's featured picture, since we want to showcase quality work first. I've made a demo here: User:Ca/sadbox. Catalk to me!13:11, 29 November 2024 (UTC)[reply]
Looks good. And it's fine if we recycle them fairly rapidly, since these are things can be easily reused – in fact, I suggest cycling this weekly instead of daily. Cremastra ‹ u — c › 15:56, 29 November 2024 (UTC)[reply]
The Main Page is deliberately aimed at readers, not editors. Its purpose is to direct readers to interesting encyclopaedic content, not show them how to edit pages. The Main Page is also very full already, so adding anything would require removing something else. I think it's highly unlikely that this idea would achieve consensus at T:MP. However I'm sure there's a place for something like this in Wikipedia: space. Modest Geniustalk12:42, 3 December 2024 (UTC)[reply]
To be fair, the whole point of Wikipedia is that readers are potential editors. Helping readers take that step would definitely help us keep a steady, or even growing, user base. Chaotic Enby (talk · contribs) 12:52, 3 December 2024 (UTC)[reply]
I am not sure what you mean by The Main Page is also very full. There isn't a size limit to Internet pages? In any case, I want the content of the tips to be reader-focused, not editor-focused. Things like creating an account to change website display, identifying who-wrote-what, etc. Catalk to me!13:14, 3 December 2024 (UTC)[reply]
This is perfect! It seems like people already done the work for me. However, there is some need to retheme the banner so that it fits in with the rest of the main page. Catalk to me!23:49, 4 December 2024 (UTC)[reply]
Uploading hundreds of files or changing thousands of pages can be tedious. Limited automation is allowed on Wikipedia as long as it follows certain policies. The easiest way is to use AutoWikiBrowser.
To add this auto-updating template to your user page, use {{totd}}
I think the OP's plan is a terrific idea. The vast majority of readers never even think about actually editing a page (despite the ubiquitous edit links). Having a big, NOTICEABLE "tip of the day" seems a great way of changing this.
An example of a good place for this would be just above "In the News", to the right of "Welcome to Wikipedia", about two inches wide and one inch high. Obviously just one possibility out of many.
But just having another small link to some variation of Help:How to edit seems futile and unnecessary.
I would strongly recommend having a two-week trial of the OP's suggestion, and then check the metrics to see whether to continue or not. ———ypn^221:33, 4 December 2024 (UTC)[reply]
Considering that I think most other of the WMF projects have something on their main page about contributing, there is a distinct lack of it on en.wiki. This could be a page spanning box with the usual links of how to get started along with the top of the day floating right in that box. Whether that box leads or ends the page is of debate but it would make sense to have something for that. Masem (t) 00:03, 5 December 2024 (UTC)[reply]
Concur. I'm averse to directly using the WP Tip of the Day (as suggested above), since that's directly to people who are *already* editors, albeit novice ones. What we really want is for people to hit the "edit" button for the first time. I suggest cycling through a few messages, along the lines of:
Want to lend a hand? Join an international volunteer effort, whether for a day or for a decade – learn how to edit Wikipedia.
Obviously these will need some finetuning, since I'd really rather not have something as cringy as "for a day or for a decade" on the Main Page, but I think the idea is there. These one-liners should be prominently displayed at the top. Cremastra ‹ u — c › 00:13, 5 December 2024 (UTC)[reply]
I agree that the messaging needs to be toward not-yet-editors, but perhaps they can be more specific? e.g.:
Did you know that you can italicize words by surrounding them with two appostrophe's? For example, The ''Titanic'' hit an iceberg and sank in 1912. appears as The Titanic hit an iceberg and sank in 1912.
See something that needs a source? Just add {{citation needed}}after the questionable sentence, or better yet, add a source yourself using <ref>www.website.com/page</ref>!
Rather see editors include material sourced to a bare url than to add without any source or even just give up with trying to add something because the ref system is hard to learn. We have bots that can do basic url to ref formats so that is less a concern. Masem (t) 00:30, 5 December 2024 (UTC)[reply]
Disambiguation pages should auto-generate
Hello all,
Per MOS:BOLD, the first appearance of an article's titular subject should be bolded, as should any alternate names for the article. When I first started editing Wikipedia, I was surprised that those were just manual boldfaces with HTML tags. I was wondering whether it would be better to apply it with something like this: " {{article main name|Apples}}, also known as {{article alternate title|Oranges|oranges}}, are a fruit. " which would display as "Apples, also known as oranges". The two templates would auto-populate the title and short description into a disambiguation page if there were multiple instances of the same name. Further, a hatnote would be auto-created (if there were multiple instances of similarly-named pages, the hatnote would lead to the disambiguation page, and if there was only one, it would lead to the other article).
I think that this would vastly improve the simplicity of maintainging disambiguation pages and hatnotes. However, it could increase barriers to entry for new users, but that could be mitigated with editnotices, template documentation, etc. It may also be difficult to implement, but I foresee bots being able to implement the work.
"Apples, also known as oranges"? I'm not sure I understand your use case for making such pages so inaccessible and code-ridden for newcomers. Aaron Liu (talk) 04:09, 1 December 2024 (UTC)[reply]
@Aaron Liu - Yeah, I see what you're saying, but I think most of the learning curve could be eliminated if, when someone tries to edit a disambiguation page, an editnotice of some sort appears and recommends that they go edit the source page.
On the technical side, disambiguation pages already have edit notices, so that part would be feasible.On the more practical side, disambiguation pages are often more complex than just listing articles with the same title. For instance, a concept might be listed in a disambiguation page even if it doesn't have an article, but is prominently mentioned at an existing page (the kind of thing that would warrant a {{R to section}} or {{R to related topic}}). Spelling variants (especially for languages written in the Arabic script where romanizations can often vary) are also grouped together in a similar page, while more subtle issues come up with partial title matches. I can also foresee the issue of organizing the disambiguation page itself, especially with things like proper names that are often (but not always) moved to a separate page. Chaotic Enby (talk · contribs) 09:41, 2 December 2024 (UTC)[reply]
Sometimes I wish consensus was on my side more, sigh. "This template should not be used for annotating links on disambiguation pages." However, thank you for pointing me to that link, that is helpful.
Looking at the three reasons given for not using them, while the first one (style issue) can be easily fixed with a new template parameter, the other two are still very much problematic. Short descriptions are not necessarily written with disambiguation pages in mind (or even consistent from one disambiguated term to the next), and different use cases of short descriptions might conflict with each other's needs. And, well, transcluding data on disambiguation pages from other pages (which is actually close to the current proposal) still brings the issue of traceability of the edits. Chaotic Enby (talk · contribs) 08:21, 4 December 2024 (UTC)[reply]
Adding a timeline of level 3 vital people
I suggested this on the other page, but there was no reply, perhaps their chats are inactive.
You can find the draft I made of the timeline here: User:Wikieditor662/Vital sandbox.
Note: I believe that the names for the time periods are not perfect (biased towards west) and there are other areas to improve before publishing but I think it's best to see whether it should be included before going further.
@Wikieditor662 Definitely looks cool and is well-designed. Perhaps you can clarify what exactly we're trying to accomplish with this (e.g., where would you like to have this displayed)? Is the purpose to identify potential changes to the Vital list, or to find vital articles to improve, or just to graphically illustrate the "more exciting" and "less exciting" periods of human history? Or something else? ———ypn^221:22, 4 December 2024 (UTC)[reply]
@Ypn^2 I'm very glad you like the design! It's meant to give a visual representation of the people on there, and to show when these people existed and how they could have interacted with each other. Now that you bring it up, this could also be a useful way for editors to see where there can be some improvements.
As for the location, the timeline could be its own page, and perhaps we could copy and paste a part of it (such as the overview) under the "people" section of vitality articles level 3.
Also, if this turns out to be a good idea, we could also create more specific timelines like this to help visualize other areas, for example level 4 / 5 philosophers, and perhaps put a part of that timeline under the History of philosophy page.
I understand this concern, and I think it's important to keep in mind that the vital articles' levels are structured to help define the priority levels for articles. Changes for who's included onto here require deep discussions and reliable reasons as to why they should be included or excluded. Wikieditor662 (talk) 03:43, 5 December 2024 (UTC)[reply]
Thanks, I've tried for a while and couldn't figure out how to change the blue text to a different color. If you know how, please let me know. I did, however, make the border of the text more black, so it should be a little easier to see now, although it may not be perfect. Wikieditor662 (talk) 06:02, 5 December 2024 (UTC)[reply]
@Ypn^2 @Fram @Chaotic Enby @Folly Mox(tagging relevant people, if you wish to be tagged / not be tagged please let me know) I've come up with a way we could conceptualize the eras outside of just Europe, which will work sort of like this:
For every era, we come up with one global, and one regional (for continent) eras. If a person matches a local era, then they'll go there, even if it's outside the bounds of the global era. However, if we can't find their regional era, then they'll go within the bounds of the global era. The global and local eras will have the same colors. Here are the eras:
Within these eras, in the individual timelines (unlike the overview, which could be broader) we can also break each era down into periods and color them slightly differently, blending in both the current era and the era that its closest to. The eras / periods may slightly differ depending on things like location and profession.
Here are the color codes for the overview, which should be more specific within individual timelines, and a person spanning across two eras will be colored in between these two eras. These are the colors which are (for the most part) currently in the timeline sandbox.
Prehistory: Black
Ancient: Brown
Post - classical history: Gold
Early modern: Blue
Middle modern: Green
Late modern: Yellow
Long nineteenth: Dark pink
Early 19th century: Orange
Contemporary: bright pink
Some example of transitional color eras:
Code for Postclassical: PCH
Code for Renaissance: Ren
Transren: colored exactly in between ren and PC
mostlyren: colored between Ren and transren
lateren: colored between Ren and mostlyren
(the same will work for the rest of the eras for the most part)
Global era: Prehistory (3 million BC - 3,000 BC) - Black - Nobody currently on there, but this could be in case someone gets added onto there one day - between humans' formation and writing being invented. This can extend much later, for example, Australia extends to its Prehistoric period until 1788, which is when it was first colonized (unless you include the age of discovery, which started in 1400).
Iron age / middle ancient - 1,200 BC - 550 BC (can also be a part of prehistory) - mostly ancient, less prehistoric
- For Iron Age Europe this is 1,050 - 776 BC (for consistency)
- Iran (for them this is still a part of pre-history): 2,000 BC - 1,000 BC
- India: 1,800 BC - 200 BC
Late ancient (or sometimes late iron ages) - 550 BC - 476 AD (every established era during this time, such as late antiquity is not global) - color: ancient
Late 20th century (L20) - 1945 - 2000 - Bright Orange (these colors will be slightly different than the overview because of the background)
-Modern Mexico: 1910 - 2000 - color: E20-L20
21st century (color: 21) - 2000 - today - Bright Pink (this will help out more in the future)
Regional time periods:
-Contemporary Mexico: 2000 - Present - color: 21
Postmodernism - The west - 1960 - Today (exact end date unclear, 20th century still applies for the individual timeline) - color: depends; some combination of L20 and 21
Don't know why you posted this in the middle of the discussion, and not clear what you want to do with it. In any case, this doesn't belong in the mainspace. If some project wants to use this in projectspace then why not, but "vital-3" articles or any variation thereof are not a notable group. Fram (talk) 08:44, 16 December 2024 (UTC)[reply]
Still not clear what you really want to do with it, but it definitely does not belong in the mainspace (as a separate article or as part of other articles), if that was your intention. "level 3 vitality figures" is pure inner Wikipedia talk, not a reliably sourced definition. If you want to use it in other namespaces, then indeed the colours need changing: blue on purple on grey is not readable at all. The names displayed are also weird. "Miguel" for Cervantes? "Joan" for Joan of Arc? Fram (talk) 15:31, 5 December 2024 (UTC)[reply]
I concur with Fram on this point, "vital articles" are only a (more or less effective) classification of which articles are a priority for the encyclopedia, it doesn't correspond to anything in use by sources. Even with deep discussions and reliable reasons, having it as a criterion would be original research. Same for any other "homemade" ranking of important people. Chaotic Enby (talk · contribs) 15:36, 5 December 2024 (UTC)[reply]
@Fram@Chaotic Enby Are you guys opposed to having this timeline completely, or just parts of it? And also, it's not based on how important people are, but the level of prioritization, which is the reason the vitality levels exist in the first place. Wikieditor662 (talk) 22:36, 5 December 2024 (UTC)[reply]
For the unfamiliar, this follows from Wikipedia:Village pump (idea lab)/Archive 62 § Timeline of significant figures, where advice was heeded, to the OP's credit.Wikieditor662, thanks for updating your visualisation to use an inclusion criterion that will not lead to as much arguing. I still think that this is not appropriate for mainspace and will not become appropriate, since the basis is fundamentally OR— even though the original research is distributed amongst the Wikipedia community rather than your own personally.I notice you've brought this up twice at WT:PVITAL, but not at the much more active WT:VA or WT:V3. You could probably just move it to a WikiProject subpage.I concede that your project is not terribly different from List of classical music composers by era, which I also don't think is a great thing to have in mainspace, but it's twenty-one years old, and predates most of our content guidelines. As an aside, it's probable that most articles in Category:Graphical timelines are problematic: Graphical timeline of the Stelliferous Era is pretty bad; Timeline of three longest supported deck arch bridge spans is also a questionable choice. None of these articles are as contentious as the one proposed here.MOS:NOSECTIONLINKS non-compliances remain, and calling out the Western bias in the chronological taxonomy is not an adequate substitute for addressing them to conform with the periodisation used by WP:VA (which they would probably want for consistency). Folly Mox (talk) 12:10, 6 December 2024 (UTC)[reply]
I still don't think old articles should be "grandfathered in" despite not fitting our more recent content guidelines, and the subjective and nearly unsourced List of classical music composers by era (whose selection is only based on the personal choices of editors, rather than any analysis of sources) shouldn't really be kept in mainspace just because of its age. Chaotic Enby (talk · contribs) 12:31, 6 December 2024 (UTC)[reply]
Photo gathering drive for town, village, and city halls
Like how Wikipedia and Wikimedia Commons has the National Register of Historic Places drives for pictures. There should be effort put into getting the town halls, village halls, and city halls pictures. Every town, every village, every borough, every city, and county has a Wikipedia page and I think they should all have a picture posted of the administrative building. Wikideas1 (talk) 08:21, 4 December 2024 (UTC)[reply]
One consideration is that shorter articles have limited space for images, and a photo of the building housing administrative offices of a politically defined place may not be the best representation of that place. It is fine to upload such pictures to Commons, but their use may not be justified in every article about a place. Donald Albury15:44, 4 December 2024 (UTC)[reply]
I like the concept, but I feel the drive would be better if any picture of a populated place would be admissible. Places like unincorporated communities and ghost towns don't have municipal buildings, but still would be bettered with a picture. Roasted (talk) 18:30, 7 December 2024 (UTC)[reply]
It's all fun and games until the photos get deleted due to a lack of freedom of panorama. If you think somewhere in Wikipedia consistently lacks building photos, there's a good chance it's a copyright issue. CMD (talk) 03:38, 11 December 2024 (UTC)[reply]
There is a systemic problem: sections on "Funding" for non-profit organizations. They are often disinformation. For example, if an organization is partly funded by the USAID, the organization will be framed as proxy of the US Federal Government. Of, if an organization is funded by the Koch Brothers, it will be framed in a suitably FUD way. This framing is often done through emphasis on certain donors, word choices and so on. Sometimes it's explicit other times subtle. I can show many examples, but prefer not to make it into a single case. The problem is systemic, since the beginning of Wikipedia.
What we need is an essay about Funding sections. Best practices, things to avoid. A link to WP:FUNDING. And some effort to go through these articles and apply the best practices described. -- GreenC18:31, 4 December 2024 (UTC)[reply]
I'm not sure that we need a separate essay on this, though perhaps a paragraph (or a couple of examples?) at Wikipedia:WikiProject Organizations/Guidelines would be helpful. Generally, the sorts of things you would expect to find in an encyclopedic summary are broad generalities ("The Wikimedia Foundation is largely funded by small donors" vs "The Met is largely funded by large donors and ticket sales") plus sometimes a 'highlights reel' ("The largest donation in the organization's history was..." or "In 2012, there was a controversy over...").
It's possible that the section should be something like ==Finances== instead of ==Funding==, as financial information about (e.g.,) whether they're going into debt would also be relevant.
Per MOS:UNLINKDATES, years are not linked by a large majority of articles. Though, many articles do link to "xxxx in ____" articles (e.g. 2000 in television or 1900 in baseball). I do not feel like these types of articles should be linked to. The topics are broad, and in some cases there are better articles to be linked to. Roasted (talk) 18:43, 7 December 2024 (UTC)[reply]
We had a discussion about this recently, although I'm unable to immediately find it. IIRC the consensus was that the links add value in some cases (and thus should be retained) and don't in others (and thus should be removed). If my memory is correct, then this is something that can only be determined at the level of the individual article or small groups of articles. In general you can be WP:BOLD, especially if a single more specific relevant article exists, but explain why you think a change is beneficial and be prepared to discuss if others disagree. I don't believe there is (or should be) a default preference either for or against these links. Thryduulf (talk) 23:32, 7 December 2024 (UTC)[reply]
"Sensitive content" labels (only for media that is nonessential or unexpected for an article's subject)
You see, many Wikipedia articles contain images or other media that are related to the article's subject, but that readers might not want to see, and have no way of avoiding if they are reading the article without prior knowledge of its contents.
For instance, the article Human includes an image which contains nudity. This image is helpful to illustrate the article's subject, but many people who read this seemingly innocuous article would not expect to see such an image, and may have a problem with it.
Of course, if someone decides to read the article Penis and sees an image of a penis, they really can't complain, since the image would just be an (arguably, essential) illustration of the article's subject, and its presence can easily be known by the reader ahead-of-time.
My solution to this is to have editors look for media or sections of an article which could be seen as having a different level of maturity compared to the rest of the article's content, then ensuring that the reader must take additional action in order to see this content, so that readers of a seemingly innocuous article would not have to see content that could be considered "shocking" or "inappropriate" when compared to the rest of the article's content, unless they specifically choose to do so.
Who gets to decide? Editors, by consensus, just like everything else.
But more pointfully, @FluffyKittehz, our usual advice is not to do this, and (importantly) to be thoughtful about image placement. For example, decide whether a nude photo is better than a nude line drawing. Decide whether the nude image really needs to be right at the top, or whether it could be a bit lower down, in a more specific section. For example, the nude photos in Human are in Human#Anatomy and physiology, which is less surprising, seen by fewer users (because most people don't scroll down) and more understandable (even people who dislike it can understand that it's relevant to the subject of anatomy).
BTW, the people in that particular nude photo are paid professional models. They were specifically hired, about a dozen or so years ago, to make non-photoshopped photos in the non-sexualized Standard anatomical position (used by medical textbooks for hundreds of years). I have heard that it was really difficult for the modeling agency to find anyone who would take the job. WhatamIdoing (talk) 03:53, 11 December 2024 (UTC)[reply]
Changes to welcome banner
I've copied and restructured content from [RfC]. My initial proposal was to remove this content entirely, but consensus seems to be against that, so I've moved most of the discussion here.
The Welcome message is valuable and it makes sense for it to be at the top; the message includes a link to Wikipedia for those unfamiliar with the site, and "anyone can edit" directs readers (and prospective editors) to Help:Introduction to Wikipedia. The article count statistic is a fun way to show how extensive the English Wikipedia has become. (My only suggestion would be to include a stat about the number of active editors in the message, preferably after the article count stat.) Some1 (talk) 15:06, 8 December 2024 (UTC)[reply]
This proposal essentially restricts informing readers about one of Wikipedia’s core ideas: anyone can edit. The current text on the main page is important because it reminds readers that we’re a free encyclopedia where anyone can contribute. The article count also matters—it shows how much Wikipedia has grown since 2001 and how many topics it covers.Another point to consider is that moving it to the bottom isn't practical. I don't think readers typically scroll that far down—personally, I rarely do. This could lead to fewer contributions from new users.The AP (talk) 15:29, 8 December 2024 (UTC)[reply]
Why on earth would we want to hide the fact that we're the free encyclopedia anyone can edit? We need more information about how to edit on the MP, not less! We want to say, front and centre, that we're a volunteer-run free encyclopedia. Remove it, and we end up looking like Britannica. The banner says who we are, what we do, and what we've built, in a fairly small space with the help of links that draw readers in and encourage them to contribute. Cremastra ‹ u — c › 17:31, 8 December 2024 (UTC)[reply]
I strongly agree with the comments above about the importance of encouraging new readers to edit. However, I'm a bit skeptical that the current approach (a banner taking up a quarter of the screen with some easter egg links) is the most effective way to achieve this—how often do people click on any of them? Anyone have ideas for other ways to accomplish this better while using the same amount of space?– Closed Limelike Curves (talk) 00:05, 11 December 2024 (UTC)[reply]
Aesthetic concerns
While the message isn't information-dense like the rest of the Main Page, it is much more welcoming for a new visitor, and easier on the eyes, than immediately starting with four blocks of text. Chaotic Enby (talk · contribs) 13:09, 8 December 2024 (UTC)[reply]
Do you have another good reason that the top of the MP should be taken down? Do you have a alternative banner in mind? Moreover, this needs a much wider audience: the ones on the board. 2601AC47 (talk·contribs·my rights) Isn't a IP anon14:27, 8 December 2024 (UTC)[reply]
This is a strange concern; of course a community consensus can change the main page's content. It doesn't seem to be happening, but that has nothing to do with the WMF. ~ ToBeFree (talk) 16:16, 8 December 2024 (UTC)[reply]
I avoided discussing specific replacements because I didn't want to get bogged down in the weeds of whether we should make other changes. The simplest use of this space would be to increase the number of DYK hooks by 50%, letting us clear out a huge chunk of the backlog. – Closed Limelike Curves (talk) 17:43, 8 December 2024 (UTC)[reply]
Opt-in content warnings and image hiding
A recent discussion about sensitive images at VPP became quite heated, for reasons, but there actually appears to be little to no opposition to developing opt-in features to help readers avoid images that they don't want to see. Currently the options are very limited: there are user scripts that will hide all images, but you have to know where to find them, how to use them, and there's no granularity; or you can hide specific images by page or filename, which has obvious limitations. I therefore thought I'd bring it here to discuss ideas for improving these options.
My idea would be to implement a template system for tagging images that people might not want to see, e.g. {{Content warning|Violence|[[Image:Man getting his head chopped off.jpg|thumb|right|A man getting his head chopped off]]}} or {{Content warning|Sex|[[Image:Blowjob.jpg|thumb|right|A blowjob]]}}. This would add some markup to the image that is invisible by default. Users could then opt-in to either hiding all marked images behind a content warning or just hiding certain categories. We could develop a guideline on what categories of content warning should exist and what kind of images they should be applied to.
A good thing about a system like this is that the community can do almost all of the work ourselves: the tagging is a simple template that adds a CSS class, and the filtering can be implemented through user scripts/gadgets. WMF involvement on e.g. integrating this into the default preferences screen or doing the warning/hiding on the server side would be a nice-to-have, not a must-have. – Joe (talk) 07:34, 11 December 2024 (UTC)[reply]
Oh also, I suggest we strictly limit discussion here to opt-in systems—nothing that will change the current default of all images always being visible as-is—because experience shows that, not only is consensus on this unlikely to change, but even mentioning it has a tendency to heat up and derail discussions. – Joe (talk) 07:36, 11 December 2024 (UTC)[reply]
Would there be a way to tag or list the images themselves, rather than needing to recreate new template coding for each use? CMD (talk) 08:32, 11 December 2024 (UTC)[reply]
That would make sense, but since the images are (mostly) on Commons I couldn't figure out a way of doing it off the top of my head. It would also mean that control of what and how things were tagged would be on another project, which always tends to be controversial on enwiki. – Joe (talk) 08:56, 11 December 2024 (UTC)[reply]
From the experience with spoiler warnings, these things tend to proliferate if they exist at all. I would rather stay with the clean policy of no warnings whatsoever than discuss whether to introduce warnings for certain classes of offensive things. I am personally offended by the use of "His Royal Highness" or similar words when referring to citizens of Germany like Mr Prinz von Preussen, but I think it is better not to have a category of pictures offending German anti-monarchists. Even if we do not do the censoring ourselves, I oppose spending volunteer time on implementing something that can be used as a censorship infrastructure. —Kusma (talk) 09:33, 11 December 2024 (UTC)[reply]
This would retain the policy of no warnings because they would be invisible to anybody who didn't opt-in. Similarly, only volunteers who want to use their time in maintaining this system would do so. – Joe (talk) 10:45, 11 December 2024 (UTC)[reply]
Strongest oppose to tagging system, for which there was pretty clear consensus against in the previous discussion. It is against the spirit of Wikipedia and would be a huge headache for an end that goes against the spirit of Wikipedia. This project should not be helping people hide from information. ꧁Zanahary꧂15:33, 11 December 2024 (UTC)[reply]
Support: I don't see why would anyone oppose it. And since I have little knowledge on technical stuff, I don't have anything to add to this idea.
Sorry, I didn’t realize we don’t vote here. How are we supposed to voice opposition to an idea? Just exclude the bolded vote? ꧁Zanahary꧂18:36, 11 December 2024 (UTC)[reply]
I don't voice opposition to an idea? Here's my criticism: tagging to appeal to sensitivities that would have certain types of information and imagery hidden is validating those sensitivities, which is not the place of Wikipedia (and is against its spirit), and enables the concealment of informationm which is diametrically opposed to the spirit of Wikipedia. My proposed "fix" is to not pursue this content-tagging idea. ꧁Zanahary꧂19:23, 11 December 2024 (UTC)[reply]
Having a general Opt-in system of blurring or hiding all images would be no problem. Having one based on tags, content, categories... would be largely unmaintainable. If you create an "opt-in here to hide all sexual images", then you have to be very, very sure that you actually can do this and not give false promises to readers. But as there is no agreement on where to draw the line of what is or isn't sexual, nudity, violence, disturbing, ... this will only lead to endless edit wars without possible resolution. Are the images on Breastfeeding sexual? L'Origine du monde? Liberty Leading the People (ooh, violence as well!)? Putto? Pavilion of Human Passions? Fram (talk) 10:03, 11 December 2024 (UTC)[reply]
Exactly. One of the issues is that some people think there is a thing such as non-sexual nudity, while others think that nudity is always sexual. —Kusma (talk) 10:14, 11 December 2024 (UTC)[reply]
So we could have a category "nudity" instead of or in addition to "sex". Part of the proposal here is coming to a consensus on which categories should exist and on guidelines for their use. I don't see how we can conclude that this is an impossible or impractical task before even trying. We manage to drawlinesthroughgreyareas all the time. – Joe (talk) 10:44, 11 December 2024 (UTC)[reply]
As with everything, we'd have to reach a consensus about such edge cases either in general or on a case-by-case basis. It's not for me to say how that would go with these examples, but I'd suggest as a general principle we should be descriptive rather than normative, e.g. if there is a dispute about what constitutes male nudity, then break the category down until the labels are uncontroversial – "male nudity (upper body)" and so on. – Joe (talk) 13:50, 11 December 2024 (UTC)[reply]
These aren't edge cases though. The more you have to break it down, the more work it creates, and the disputes will still continue. Will we label all images of women/men/children/other? All images of women showing any flesh or hair at all? Basically, we will need to tag every image in every article with an endless series of tags, and then create a system to let people choose between these endless tags which ones they want to hide, even things most of us might find deeply unsettling to even offer as an option? Do we want people to be able to use Wikipedia but hide all images of transgenders? All images of women? All images of Jews? Everything that isn't halal? In the 4 images shown below, the one in the bathtub is much more sexual than the one in the shower, but the one in the shower shows a nipple, and the other one doesn't. Even to only make meaningful categories to indicate the difference between those two images would be quite a task, and then you get e.g. the other image showing an artwork, which again needs a different indication. It seems like madness to me. Fram (talk) 14:05, 11 December 2024 (UTC)[reply]
There are just so many things that some people don't want to see... Dead Australians or Baháʼu'lláh are among the easier ones that might look near harmless to tag. However, people will also demand more difficult things like "images not appropriate for 12 year olds" that have no neutral definition (and where Europeans and Americans have widely differing opinions: just look for typical film ratings where European censors think sex, nudity, drug use and swearing are ok but violence is not, and American censors will think the opposite). There are also things some people find offensive that I am not at all ok with providing a censorship infrastructure for: images depicting mixed-race couples, images depicting trans people, images depicting same-sex couples. I do not think Wikipedia should help people avoid seeing such images, so I do not want us to participate in building a censorship infrastructure that allows it. —Kusma (talk) 11:18, 11 December 2024 (UTC)[reply]
The English Wikipedia community would control which categories are used for this system and I am confident they would reject all of these examples. "People will make unreasonable demands" does not sound like a good reason not to do something. – Joe (talk) 13:44, 11 December 2024 (UTC)[reply]
I am confident they would reject all of these examples Why? On what objective grounds are you labelling those examples as "unreasonable"? Why are your preferences "reasonable"? Thryduulf (talk) 14:14, 11 December 2024 (UTC)[reply]
Because if there's one thing the English Wikipedia community is known for, it'a always agreeing on everything?
This project already has enough things for ongoing arguments over. Making lists of what people may want to avoid and ranking every image on whether it falls into that list is a tremendous effort that is bound to fail. (The thread calling for such categorization on the policy page is an excellent example.... a user felt they were harmed by an image of a dead man smiling... only it seems not to be a dead man, we were supposed to police that image based on how they would misinterpret it.) I'm also wondering if we risk civil litigation if we tell people that we're protecting against image-type-X and then someone who opted out of seeing such images views something that they consider X.
This is just one more impediment to people adding information to the encyclopedia. I can't see that this censorship system would make more people enthusiastic to edit here (and if it did, I'm not sure we'd really want the sort of editor it would encourage.) -- Nat Gertler (talk) 14:39, 11 December 2024 (UTC)[reply]
One more general problem with the proposal is that you do not know whether people will be forced to "opt in" by "well meaning" system administrators trying to censor what can be accessed from their system. Having machine readable tags on images makes it very easy to do so and also easy to remove people's ability to click through and see the content. We should not encourage volunteer efforts on supporting such censorship infrastructures. —Kusma (talk) 11:46, 11 December 2024 (UTC)[reply]
I don't think the specific proposal here, placing templates in articles (even if they default to not obscuring any images), would be workable. It's too big of an opportunity for activist editors to go on mass-article-editing sprees and for people to edit war over a particular instance of the template. You'd also have to deal with templates where simply wrapping the image in a template isn't currently possible, such as Template:Speciesbox. If people really want to pursue this, I think it'd be better to figure out how to tag the images themselves; people will still probably fight over the classifications, but at least it's less likely to spill over into disrupting articles. Anomie⚔12:45, 11 December 2024 (UTC)[reply]
The idea was that, since these templates would have no effect if not someone has not opted-in to hiding that specific category of image, people who do not want images to be hidden would be less likely to fight over it or be worried about what "activist editors" are doing. The idea that Wikipedia should not be censored for everyone has solid consensus behind it, but the position some are taking here, that other people should not be allowed an informed choice of what not to see, strikes me as quite extreme. – Joe (talk) 13:40, 11 December 2024 (UTC)[reply]
I dispute your good-faith but naive assertion that these templates would have "no effect on people who have not opted in". If you tag images systematically, you make it easy to build proxies (or just censored forks) that allow high schools in Florida to ensure their students won't be able to click through to the photo explaining how to use contraceptives. There is no innocent "only opt-in" tagging; any such metadata can and will be used for censorship. Do you really want us to be in the business of enabling censorship? —Kusma (talk) 15:14, 11 December 2024 (UTC)[reply]
Well yes, the proposal literally to enable censorship. For those who want it. It may be that it is used by network administrators as you suggest, we can't stop that, but that's between them and their users. I agree that censorship should not affect what editors include in our content but I find the idea that we can enforce our ideal of Zero Sensitivity Free Speech to a global readership also very naive (and frankly a little creepy; I keep picturing a stereotypical Wikipedian standing in front of a Muslim child screaming "no you WILL look at what we show you, because censorship is bad and also what about Renaissance art"). A silver lining could be that the option of controlling access to our content in a fine grained way may convince some networks to allow partial access to Wikipedia where they would otherwise completely block it. – Joe (talk) 16:58, 12 December 2024 (UTC)[reply]
We are not in the business of enabling censorship, voluntary or otherwise, because voluntary censorship very quickly becomes involuntary cesnsorship. We are in the business of providing access to information, not inhibiting access to information. Thryduulf (talk) 17:07, 12 December 2024 (UTC)[reply]
"We're not in the business of leaving the phrase 'rimjob' to your imagination, Timmy, we're in the business of providing access to artistic depictions of bunny sex!" he screamed, and screamed, and screamed... you guys are really silly sometimes. – Joe (talk) 17:31, 12 December 2024 (UTC)[reply]
I've seen enough arguments over people doing mass edits and otherwise fighting over invisible stuff in articles, including complaints of watchlist flooding, to think this would be any different. Anomie⚔00:17, 12 December 2024 (UTC)[reply]
Antonin Carlès (1851-1919) - La Jeunesse (1883) (12387743075)Angela milk tub (LR-6395)Adult Caucasian woman - Breast Self-Exam (1980)Nude woman private portrait
* I would support an opt-in that turned off or blurred all images and made them viewable with a click. I would absolutely object to anything that used some categorization system to decide which images were potentially offensive to someone somewhere. There would be systemic sexism in such categorization because of different cultural norms. Valereee (talk) 12:56, 11 December 2024 (UTC)[reply]
Yes, or at least the three photographs. I'm standing on a crowded subway car and just scrolled past three pics of boobs. Totally unexpected, totally would have minimized/blurred/hidden those if I could, just for the other people around me. It has nothing to do with being offensive, I'm just in a place where pictures of boobs are not really OK to have on my phone right now. And I live in a free country, I can only imagine what it might be like for others. Levivich (talk) 15:16, 11 December 2024 (UTC)[reply]
If you are in a place where images of boobs are not ok to have on your phone, you should turn off or blur images on wikis in general as you can never guarantee there will be a warning. (As an aside, these images are not far from some that I have seen in on ads in subway stations). —Kusma (talk) 16:15, 11 December 2024 (UTC)[reply]
Levivich, I sympathize with the desire not to encounter NSFW content while “at work”. But your standard here is “not safe for a crowded American or British public space”, which admittedly is the default for the Internet as a whole. But on Wikimedia we at least try to respect the fact that not everyone has that standard. Dronebogus (talk) 17:49, 11 December 2024 (UTC)[reply]
It really doesn't feel like we're trying to respect anyone, based on this and related discussions. We seem to be saying to anybody who has personal or cultural sensitivities about any kind of image (so the majority of humankind) that they can either accept our standard of WP:NOTCENSORED or to not see any images at all. We're saying we can't possibly let your kids have the full experience of our educational images while also avoiding photos of dead bodies or graphic depictions of penetrative sex, because what about male nipples? – Joe (talk) 17:04, 12 December 2024 (UTC)[reply]
I don't think anyone is saying that people should not see images at all... simply that if they are concerned about seeing images, they get to be the ones to decide which images they should see by clicking on that image. For them to make it our responsibility to guess which pictures they'll want and be the baddies when we're wrong is not respecting them and their ability to make decisions for themselves. (And I'm not sure that you can say we're giving anyone the "full experience of our educational images" when you are hiding some of them.) -- Nat Gertler (talk) 21:10, 12 December 2024 (UTC)[reply]
Yes because what about male nipples. Because what about female nipples? Lots of more liberal-minded legal guardians wouldn’t oppose children seeing those. Or even full nudity. Or even dead bodies and penetrative sex! And then we have to go the whole opposite direction ad absurdum with women in bikinis, and Venus de Milo, and unveiled females, or female humans in general, and Mohammad, and dead aboriginal Australians and spiders and raw meat and Hindu swastikas and poop. Dronebogus (talk) 11:27, 13 December 2024 (UTC)[reply]
Try that with the policeman looking over your shoulder in the country where accessing "indecent" images gets you imprisoned. – Joe (talk) 17:06, 12 December 2024 (UTC)[reply]
Pretty much every image of a human being (and plenty of other subjects) has the potential to be regarded as indecent somewhere. This means there are exactly two options that can achieve your desired outcome: censor all images, or assigned every image, individually, to one or more extremely fine-grained categories. The first already exists, the second is completely impractical. Thryduulf (talk) 17:11, 12 December 2024 (UTC)[reply]
Someone on the subway asked me to stop looking at pictures of naked people on my phone and I said "WHAT?! I'M READING AN ENCYCLOPEDIA!" Levivich (talk) 00:22, 13 December 2024 (UTC)[reply]
I really don’t see why Wikipedia should work around the subway-goer looking at your phone and your ability to appease them. Look at another website if you want something censored and safe for onlookers. ꧁Zanahary꧂00:28, 13 December 2024 (UTC)[reply]
You can have your own script to toggle off every image. You can have a script that runs on an off-wiki index of images you don’t want to see. But to tag images as potentially offensive, I have an issue with, and I hope you understand why even if you don’t agree. ꧁Zanahary꧂02:44, 13 December 2024 (UTC)[reply]
I’m sorry but your situation is just weird. You should know Wikipedia is generally NSFW at this point if you’re complaining about it right now. Dronebogus (talk) 11:45, 13 December 2024 (UTC)[reply]
Seems that the problematic behavior here isn't us having the images or you looking at them, it is the random person looking at someone else's screen. We should not be required to modify our behavior because other people behave badly. --User:Khajidha (talk) (contributions) 15:49, 13 December 2024 (UTC)[reply]
You can look at other websites if you're in public and an uncensored one would disturb people who might glance at your phone! ꧁Zanahary꧂21:06, 11 December 2024 (UTC)[reply]
I'd be ok with such an opt-in too, if it can be made. Perhaps such a link/button could be placed in the main meny or floating header. The hamburger too perhaps, for the mobile readers. Gråbergs Gråa Sång (talk) 13:27, 11 December 2024 (UTC)[reply]
The idea is not to decide what is and isn't potentially offensive, but to add descriptive labels and then let readers decide what they do and do not want to be warned about. So for example we would not categorise any of your examples as "potentially offensive", but as containing "nudity" or "nude women" or whatever level of granularity was agreed upon. This idea is a reaction to the proposal to obscure all images (which is being discussed elsewhere) because a) letting users choose whether to see an image is only useful if they have some indication of what's behind the blurring and b) quite frankly, I doubt anyone will ever use such an indiscriminate option. – Joe (talk) 13:33, 11 December 2024 (UTC)[reply]
One generally does have indications of what is being blurred, both some sense in a blurred image but more importantly by caption. Some ways of hiding all images would ipresent not a blurred image present a filename, and image filenames are largely descriptive. -- Nat Gertler (talk) 15:59, 11 December 2024 (UTC)[reply]
That is actually a much better idea than blurring, thanks! Having a "see alt text instead of images" option would not only be more practical for people wanting to know if images are sensitive before seeing them, it would also give more of an incentive to add alt text to begin with. Chaotic Enby (talk · contribs) 18:31, 11 December 2024 (UTC)[reply]
I would also support an opt-in to blur all images (in fact, User:Chaotic Enby/blur.js does about that). However, categorizing images with labels whose only purpose is for reader to decide whether they are offensive is, by definition, flagging these images as "potentially offensive", as I doubt a completely innocuous image would be flagged that way. And any such categorization can easily be exploited, as above.Also, the ethical concerns: if some people find homosexuality offensive, does that mean Wikipedia should tag all images of gay couples that way? What is the message we bring if gay people have a tag for blurring, but not straight people? Chaotic Enby (talk · contribs) 14:04, 11 December 2024 (UTC)[reply]
You might be able to do it using categories, even Commons categories. Instead of (or in addition to) adding images one by one to special maintenance categories, add entire image categories to the maintenance categories. Keep in mind this isn't the kind of thing that needs consensus to do (until/unless it becomes a gadget or preference)--anyone can just write the script. Even the list of categories/images can be maintained separately (e.g. a list of Commons categories can be kept on enwiki or meta wiki or wherever, so no editing of anything on Commons would be needed). It could be done as an expansion of an existing hide-all-images script, where users can hide-some-images. The user can even be allowed to determine which categories/images are hidden. If anyone wants to write such a script, they'd have my support, hmu if you want a tester. Levivich (talk) 15:30, 11 December 2024 (UTC)[reply]
To get any sort of useful granularity you have to go multiple levels deep, and that means there are literally thousands (possibly tens of thousands) of categories you need to examine individually and get agreement on. And then hope that the images are never recategorised (or miscategorised), new images added to categories previously declared "safe" (or whatever term you choose) or new categories created. Thryduulf (talk) 15:43, 11 December 2024 (UTC)[reply]
c:Category:Penis. If someone wrote a script that auto-hid images in that category (and sub-cats), I'd install it. We don't need agreement on what the categories are, people can just make lists of categories. The script can allow users to choose whatever lists of categories they want, or make/edit their own list of categories. One thing I agree about: the work is in compiling the lists of categories. Nudity categories are easy; I suspect the violence categories would be tougher to identify, if they even exist. But if they don't, maintenance categories could be created. (Lists of individual images could even be created, but that is probably too much work to attempt.) Levivich (talk) 15:53, 11 December 2024 (UTC)[reply]
Going that private script route, you could also use the category of the article in which it appears in some cases. But I'd worry that folks would try to build categories for the specific reason of serving this script, which would be sliding from choice to policy. -- Nat Gertler (talk) 16:02, 11 December 2024 (UTC)[reply]
Nah, still choice. One option is to create new maintenance categories for the script. Another option is for the script to just use its own list of images/categories, without having to add images to new maintenance categories. Levivich (talk) 16:21, 11 December 2024 (UTC)[reply]
Allowing maintenance categories designed to hide images is very much a policy issue, no matter how many times you say "nah". The moment that "pictures which include Jews" category goes up, we're endorsing special tools for antisemitism. -- Nat Gertler (talk) 17:04, 11 December 2024 (UTC)[reply]
Nah. See, while we have a categories policy, new maintenance categories are not something we "allow" or don't allow -- they're already allowed -- and they don't create a "policy issue" because we already have a policy that covers it. People create new maintenance categories all the time for various reasons -- it's not like we have to have an RFC to make a new template or make a new maintenance category. This is a wiki, have you forgotten? We need consensus to delete stuff, not create stuff.
And you're totally ignoring the part that I've now said multiple times, which is that no new maintenance categories are required. That's one way to skin this cat, but it can also be done by -- pay attention please -- creating lists of categories and images. See? No maintenance category, no policy issue.
Anybody creating a list of "pictures which include Jews" would be violating multiple site policies and the UCOC and TOS. This is a wiki, remember? Did we not have Wikipedia because someone might create an antisemitic article? No! We still had a Wikipedia, knowing full well that some people will abuse it. So "somebody might abuse it!" is a really terrible argument against any new feature or script or anything on Wikipedia.
What are you even opposing here? You have a problem with someone creating a script to hide images? Really? Maybe just ... not ... try to imagine reasons against it? Maybe just let the people who think it's a good idea discuss the implementation, and the people who don't think it's a good idea can just... not participate in the discussion about implementation? Just a thought. It's hard to have a discussion on this website sometimes. Levivich (talk) 17:09, 11 December 2024 (UTC)[reply]
Creating a script to hide images is fine. Curating/categorising images to make them easier to hide is not. You are free to do the first in any way you like, but the second should not be done on Wikipedia or any Wikimedia project. —Kusma (talk) 17:30, 11 December 2024 (UTC)[reply]
Why yes, I can understand why having people who disagree with you about both intent and effect in this matter would be a disruption to the discussion you want to have, with all agreeing with you and not forseeing any problems nor offering any alternate suggestions. I'm not seeing that that would be particularly in the spirit of Wikipedia nor helpful to the project, however. "Someone might abuse it and it might require more editorial effort to work it out, all of which could be a big distraction that do not actually advance the goals of the project" is a genuine concern, no matter how many times you say "nah". -- Nat Gertler (talk) 17:40, 11 December 2024 (UTC)[reply]
If not categories then perhaps that image tagging system commons has? (Where it asks you what is depicted when you upload something). Not sure how much that is actually used though. – Joe (talk) 17:18, 12 December 2024 (UTC)[reply]
Yeah, given how Wikipedia categorization works (it's really labeling, not categorization), it's well known that if you go deep enough into sub-cats you emerge somewhere far away from the category you started at.
If the cost of muting the Penis category is having the bunny picture hidden, I'd still install the script. False positives are nbd. Levivich (talk) 16:23, 11 December 2024 (UTC)[reply]
And...? I thought we were hiding objectionable images (and considering that painting as "objectionable" is dubious to start with), not all images on a page where one image is objectionable? Plus, an image that is only used on page X today may be used on page Y tomorrow ("rabbits in art"?). So no, this is not a bad example at all. Fram (talk) 22:54, 13 December 2024 (UTC)[reply]
This is no better than the discussion running at the other VP and is borderline forum shopping. I’m disappointed in the number (i.e. non-zero) of competent users vehemently defending a bad idea that’s been talked to death. I keep saying that the only way (no hyperbole) this will ever work is an “all or nothing” opt-in to hide all images without prejudice. Which should be discussed at the technical VP IMO. Dronebogus (talk) 17:37, 11 December 2024 (UTC)[reply]
Maybe you missed it, ValarianB, but this is the idea lab, so a) as it says at the top of the page, bold !voted are discouraged and b) the whole point is to develop ideas that are not yet ready for consensus-forming in other forums. – Joe (talk) 17:10, 12 December 2024 (UTC)[reply]
Maybe you missed it, @Joe, but forum shopping, spending time developing ideas that have no realistic chance of gaining consensus in any form, and ignoring all the feedback you are getting and insisting that, no matter how many times and how many ways this exact same thing has been proposed previously, this time it won't be rejected by the community on both philosophical and practical grounds are also discouraged. Thryduulf (talk) 17:16, 12 December 2024 (UTC)[reply]
Yes, that's exactly the problem with forum shopping. If you keep starting new discussions and refusing to accept consensus, you might exhaust people until you can force your deeply unpopular idea through.135.180.197.73 (talk) 18:31, 12 December 2024 (UTC)[reply]
Because Thryduulf apparently thinks it's a waste of time to do so. And since the purpose of the idea lab is to develop an idea, not propose or build consensus for anything, I tend to agree that chiming in here just to say you oppose something is a waste of (everyone's) time. – Joe (talk) 18:43, 12 December 2024 (UTC)[reply]
How? If I were workshopping an idea to make Wikipedia cause laptops to explode, a discussion that omits opposition to that idea would be useless and not revealing. ꧁Zanahary꧂19:56, 12 December 2024 (UTC)[reply]
Because you're not participating to help develop the idea, your participating to stop other people from developing the idea. Brainstorming is not a debate. Brainstorming an idea does not involve people making arguments for why everyone should stop brainstorming the idea.
To use an analogy, imagine a meeting of people who want to develop a proposal to build a building. People who do not think the building should be built at all would not ordinarily be invited to such a meeting. If most of the meeting were spent talking about whether or not to build the building at all, there would be no progress towards a proposal to build the building.
Sometimes, what's needed (especially in the early stages of brainstorming) is for people who want to develop a proposal to build a building, to have the space that they need to develop the best proposal they can, before anybody challenges the proposal or makes the argument that no building should be built at all. Levivich (talk) 20:13, 12 December 2024 (UTC)[reply]
The issue here is that image filtering for this purpose is a PEREN proposal, with many of the faults in such a system already identified. Not many new ideas are being proposed here from past discussions. Masem (t) 20:27, 12 December 2024 (UTC)[reply]
I don't think this model works for a wiki. There's no committee presenting to the public. This project is all of ours, and if there's so much opposition to a proposal that it cannot be discussed without being overwhelmed by opposition, then I don't see it as a problem that the unpopular idea can't get on its feet. ꧁Zanahary꧂20:43, 12 December 2024 (UTC)[reply]
There's no problem with users voluntarily discussing an idea and how it might be implemented. They should, of course, remain aware that just because everyone interested in an idea comes up with a way to proceed doesn't mean there's a community consensus to do so. But if they can come up with a plan to implement an add-on feature such as a gadget, for example, that doesn't impose any additional costs or otherwise affect the work of any other editor who isn't volunteering to be involved, then they're free to spend their own time on it. isaacl (talk) 19:33, 12 December 2024 (UTC)[reply]
My personal thought on how this should work is image sorting by category, the onus is completely on the user using the opt-in tool to select categories of images they don't want to see. We don't need to decide for anybody, they can completely make their own decisions, and there's no need for upkeep of a "possibly offensive image list." Just Step Sidewaysfrom this world ..... today02:48, 13 December 2024 (UTC)[reply]
It’s interesting but I don’t support it. People don’t necessarily get how categories work. “Sex” isn’t about sexual intercourse, but it’ll be at the top of everyone’s block lists. And blocking a huge over-category like violence will block a lot of totally inoffensive images. In other words, this is too technical for most people and will satisfy no-one while catching mostly false positives. Which is actually worse than all-or-nothing. Dronebogus (talk) 11:19, 13 December 2024 (UTC)[reply]
A problem with this is that the tail may begin to wag the dog, with inclusion on block lists becoming a consideration in categorizing images and discussions on categorizations. ꧁Zanahary꧂15:00, 13 December 2024 (UTC)[reply]
Suggestion: we let those who think this is a good idea waste hours of their time devising a plan, and then we oppose it once they bring it to WP:VPPR. I guess they have received enough feedback and can look through the archives to see why this is a bad idea which has been rejected again and again. It's their choice if they want to add one more instance of this perennial proposal, if they believe that either the opposes here are a minority and they represent the silent majority somehow, or if they somehow can find a proposal which sidesteps the objections raised here. Fram (talk) 11:46, 13 December 2024 (UTC)[reply]
It'd be better for labels to be attached to images and not to inclusions of them
It'd be better to use an existing labelling (e.g. categories, captions) rather than a new system
However it's doubtful if it's feasible to use categories or if they are sufficiently consistent
An alternative could be to maintain a central list of labels
This suggests to me three, not mutually exclusive approaches: obscure everything any rely on captions and other existing context to convey what's shown (which is being discussed at Wikipedia:Village_pump_(proposals)#"Blur_all_images"_switch); develop a gadget that uses categories (possibly more technically complex); develop a gadget that uses a central list (less technically complex, could build lists from categories). – Joe (talk) 12:11, 13 December 2024 (UTC)[reply]
…this is your summary of feedback so far? How about "many editors believe that marking content as potentially sensitive violates WP:NOTCENSORED and the spirit of an encyclopedia?" ꧁Zanahary꧂14:58, 13 December 2024 (UTC)[reply]
That viewpoint has been well-heard and understood, and any actual implementation plan that develops will have to take it into account. isaacl (talk) 17:23, 13 December 2024 (UTC)[reply]
My main questions would be what the criteria are for deciding what labels to have, and what steps would be taken to minimize the prejudicial effects of those labels (see Question 7 in this ALA Q&A)? (Asking in good faith to foster discussion, but please feel free to disregard if this is too contrarian to be constructive.)--Trystan (talk) 16:49, 13 December 2024 (UTC)[reply]
I think it'd be best if the user sets their own exclusion list, and then they can label it however they want. Anyone who wants to could make a list. Lists could be shared by users if they want. Levivich (talk) 18:20, 13 December 2024 (UTC)[reply]
One option would be to start with an existing system from a authorative source. Many universities and publishers have guidelines on when to give content warnings, for example.[22] – Joe (talk) 19:23, 13 December 2024 (UTC)[reply]
This is a review of what content warnings and trigger warnings exist, not guidelines on when they should be used. It examined electronic databases covering multiple sectors (n = 19), table of contents from multi-sectoral journals (n = 5), traditional and social media websites (n = 53 spanning 36 countries), forward and backward citation tracking, and expert consultation (n = 15), and no encyclopedia. ꧁Zanahary꧂19:46, 13 December 2024 (UTC)[reply]
Yep, that's why I linked it; to show that we have at least 136 potential models. Though if you read further they do also come up with their own "NEON content warning typology" which might not be a bad starting point either. – Joe (talk) 20:02, 13 December 2024 (UTC)[reply]
It seems like getting something running for images is enough of a challenge, both technically and w.r.t to community consensus. – Joe (talk) 07:59, 16 December 2024 (UTC)[reply]
Bet you can't name three encyclopedias that contain a picture of anal sex. Britannica, World Book, and Encarta don't, in any edition. Seems that not having pictures of anal sex is quite compatible with the nature of an encyclopedia. Wikipedia might be the first and only encyclopedia in history that contains graphic images. Levivich (talk) 00:42, 14 December 2024 (UTC)[reply]
But it does make me wonder whether anything that appears only in Wikipedia and not in other general-purpose encyclopedias is accurately described as "the nature of an encyclopedia". That sounds more like "the nature of (the English) Wikipedia". WhatamIdoing (talk) 01:18, 14 December 2024 (UTC)[reply]
Wikipedia has long ago stopped being similar to old general purpose encyclopaedias; it is a sui generis entity constrained only by WP:NOT. We do have massive amounts of specialist topics (equivalent to thousands of specialist encyclopaedias) and try to illustrate them all, from TV episodes to individual Biblical manuscripts to sex positions. —Kusma (talk) 07:40, 14 December 2024 (UTC)[reply]
I believe that the argument is that since Wikipedia is the only (known) general-purpose encyclopedia to include such photos, then their absence could not be "fundamentally incompatible with the nature of an encyclopedia". If the absence of such photos were "fundamentally incompatible with the nature of an encyclopedia", then Wikipedia is the only general-purpose encyclopedia that has ever existed. WhatamIdoing (talk) 02:10, 14 December 2024 (UTC)[reply]
Why shouldn’t we operate from the idea that Wikipedia is the ideal encyclopedia? To me it clearly is. The spirit of an encyclopedia is obviously better served with photos on the article for anal sex than with a lack of them. ꧁Zanahary꧂03:09, 14 December 2024 (UTC)[reply]
Because, as people who have a significant say in what Wikipedia looks like, that would be incredibly solipsistic and automatically lead to the conclusion that all change is bad. – Joe (talk) 06:00, 14 December 2024 (UTC)[reply]
Taken to extremes, all philosophies would pitfall into pointlessness. If we exclude illustrating images because Britannica and World Book do too, then we may as well just fuse with either of those, or shut down Wiki because those others have it covered. Photos of an article subject are educational illustrations, and encyclopedias that lack such photos are weaker for it. ꧁Zanahary꧂06:20, 14 December 2024 (UTC)[reply]
The right approach to take here is to use the depicts statement on Commons images (see also c:Commons:Structured data). This should have a fairly high true positive ratio (compared either to picking out specific images or using categories) as the intention of the property is to be pretty concrete about what's appearing in the file (see also c:Commons:Depicts and/or c:Commons:Structured data/Modeling/Depiction - it's not obvious to me which is the Commons preference for how to depict things). You'll need to figure out which Wikidata items you want to offer which indicate a screened image, but that can start in the penis, Muhammad, internal organ, and sex directions and go from there. The gadget will probably want to support querying the subclass chain of the Wikidata item (property P279) so that you can catch the distinction between any penis and the human penis. My impression of the problem in using depicts statements is that the structured data work on Commons is much younger than the categories work is and so you're probably going to end up with more false negatives than not. It's a wiki though, so the right way to improve those cases should be obvious, and can perhaps even start with a database query today tracking which images used in our articles do not yet have depicts statements. The other problem this direction is that it doesn't take into account images hosted locally since those don't have structured data, but I anticipate the vast majority of the kinds of images this discussion entertains are free images. Izno (talk) 10:09, 14 December 2024 (UTC)[reply]
This is sounds like a very promising approach POV, thanks. I have to say I also had the strong impression that the "depicts" feature was abandonware, but then again maybe having a concrete use for the labels will prompt people to create more of them. – Joe (talk) 08:06, 16 December 2024 (UTC)[reply]
I don't see consensus in this discussion to create a new tagging/labelling system or to use existing Commons categories to hide images. People can argue until they're blue in the face, but the proposal(s) will ultimately be rejected at a community-wide RfC. That aside, I don't believe anyone here is opposed to having a toggle button that blurs or hides all images, right? The toggle switch could be placed in the Settings menu (on mobile view) or Appearance menu (on desktop view), and it would be switched off by default (meaning if editors want to blur/hide all images, they would have to manually switch it on). Only the WMF team has the ability to create such a feature, so that logged-out users can use it and logged-in users won't need to install user scripts. That idea could be suggested at the m:Community Wishlist. Some1 (talk) 15:31, 15 December 2024 (UTC)[reply]
@Some1: This is the idea lab. Discussions here are explicitly not about developing consensus one way or another (see the notice at the top of this page). The blur all images approach is being discussed elsewhere (linked several times above) and I would prefer to keep this on the original topic of labelled content warnings. – Joe (talk) 08:01, 16 December 2024 (UTC)[reply]
I feel like this section is trying to give false legitimacy to a widely opposed idea by saying the longstanding consensus that “content warnings and censorship are bad” (and by extension the opinions of anyone supporting that position) is illegitimate because it’s not “constructive”. People have a right to not help you “construct” an idea that’s against policy and been rejected time and time again. If you don’t want negativity don’t make a controversial proposal. Dronebogus (talk) 15:40, 15 December 2024 (UTC)[reply]
Making voluntary "reconfirmation" RFA's less controversial
Recently, there have been two "reconfirmation" RFA's from ex-admin candidates whose resignations weren't under a cloud. The RFA's received quite a few comments about the utility of the RFA's themselves. These are Worm That Turned's recent RFA and the ongoing RFA from Hog Farm. In both, there are multiple recurring comments, such as:
The candidate could/should have just gone to WP:BN to request the tools back
The reconfirmations were/are a "waste of community time"
The reconfirmations are a good thing, in order to increase transparency and give feedback to the candidate
I'm opening the topic here so that we can hash out ideas of making these situations less controversial, as this was a big talking point in both RFA's, and both sides are (in my view) making good points.
My initial proposal to improve this situation would be enacting the following:
Admins who resigned under their own volition (not under a cloud) who want the role back should be discouraged from opening formal RFA's and instead encouraged open a request at WP:BN
The standard holding period between a re-syssop request being posted on WP:BN and it being enacted should be increased from 24 hours to 5 days.
Whenever there is a resyssop request, a short notice should be posted to WP:AN and in WP:CENT. This notice does not explicitly ask for public input, or encourage anyone to support or oppose - just merely makes the request more visible. Anyone is free to comment on the topic at WP:BN, if they feel it necessary.
The request at WP:BN is enacted at the discretion of the bureaucrats, per the process they currently use, taking any comments that arise into account. It is explicitly not a vote.
This proposal would allow resyssopings to be more open and allow discussion when necessary, without being as public and time-demanding as a full RFA. Any thoughts on this? BugGhost🦗👻15:18, 15 December 2024 (UTC)[reply]
Oppose the first bullet. This seems to presuppose that reconfirmation RFAs are a "waste of community time" or similar, a position I cannot agree with. Reconfirmation RFAs definitively show whether someone does or does not have the trust of the community to be an admin, this is a Good Thing and they should be encouraged not discouraged. RFA is not overloaded (far from it), and nobody is compelled to participate - if you don't have anything useful to say, and don't want to spend any time investigating whether they are trustworthy or not then don't: just trust your fellow community members in the same way that you trust the 'crats. I don't oppose the other points, but absent evidence of a problem that needs to be solved, I don't see any particular benefit in them. Thryduulf (talk) 15:43, 15 December 2024 (UTC)[reply]
The first bullet wasn't intended to concede that they're "a waste of community time" - I personally don't think they're that useful, but I think calling them a waste of time is a bit far, as I do agree with their intended purpose. The reason why it was in quotes was because it's the phrase being debated at the current RFA's comments. The first bullet is simply intended to just say "the venue should be WP:BN, not RFA", and the subsequent bullets are just to make BN more accommodating for that purpose, and attempts to draw the attention of those that do have something to say. This proposal isn't to stop the general concept of reconfirmation or public scrutiny when resyssoping, just to alleviate the concerns that have been raised by a significant number of people in both RFAs. BugGhost🦗👻15:59, 15 December 2024 (UTC)[reply]
To further clarify: one intent of this proposal is to make making a BN request a more transparent and accountable route - less (as Hog Farm put it) "back-doorsy", in order to make all resyssopings go under a public lens, so that ex-admins don't feel like they should go under a full RFA to be fairly reapproved. If ex-admins are opening RFAs because they think the BN route doesn't give enough accountability or visibility, we should bake more accountability and visibility in. BugGhost🦗👻17:00, 15 December 2024 (UTC)[reply]
If a request needs more accountability and visibility than BN, then RFA is the correct venue to achieve that. Instead of making BN more like RFA, we should be encouraging editors to use RFA instead. This will, as others have pointed out, hopefully have the side effect of decreasing the problems at first-time RFAs. Thryduulf (talk) 21:50, 15 December 2024 (UTC)[reply]
I don't think there's anything here that needs to be fixed. Perhaps over time, the RfA route will become more popular, in which case we may choose to do away with the BN route. Or the opposite will happen, in which case no changes are necessary. Either way, this is much ado about nothing at the moment. – bradv15:53, 15 December 2024 (UTC)[reply]
I personally don’t see a major problem with re-RFA’s remaining an occasional thing where a former admin prefers it, but if a large number of editors do I think your proposal is a nice way to solve that while providing a slightly more deliberative process for returning admins who feel uncomfortable presuming that there is still consensus for their continued use of the tools.
Alternatively, we could do a bit of a petition process like with recall for editors who have been gone for more than a short, planned, absence. If few editors oppose it, the bureaucrat-led process can take place, but if more than some threshold of editors call for it, a re-RFA is required to confirm the return of tools.
That seems kinda potentially unpleasant though, so I’d support the status quo as my first choice, and your proposal as a second choice, and something like what I mentioned as a distant third.
I do think a humility before the will of the community is laudable in admins, and that the occasional easy-confirm re-RFAs would probably contribute to reducing the temperature of RFAs generally if they weren’t getting bogged down with arguments about the process. — penultimate_supper 🚀 (talk • contribs)18:09, 15 December 2024 (UTC)[reply]
Personally, I think RFA would be less toxic in general if it was less of a special occasion, and so I don't see any reason to limit these. The people who are upset by these RFAs are people whose opinions I usually both respect and understand, and in this case I can respect them but continue to not understand them. Maybe this is my problem; I'm open to being convinced. -- asilvering (talk) 18:40, 15 December 2024 (UTC)[reply]
I follow Asilvering on this point – if we make RfAs less of a special occasion, it will, down the line, have a positive effect for everyone involved: prospective new admins, admins going through a RRfA, and regular editors now having less pressure to !vote in every single RfA. Chaotic Enby (talk · contribs) 22:08, 15 December 2024 (UTC)[reply]
What if we fast-track them? Uncontroversial reconfirmations don't need to be a week; let's just let the 'crats snowclose them after 48 hours if they can be snowclosed and have right of resysop. theleekycauldron (talk • she/her) 18:52, 15 December 2024 (UTC)[reply]
Let them redo RfA if they want. Editors need to chill out. For those worrying about "straining editor time" or whatever, there's no need to participate in an RfA. You don't have to follow it. It doesn't have to take any significant portion of your time at all. The 'crats are good enough to know how to handle whatever arguments are made by those who give them and come to a decision. Plus, it's not like this is a super common thing. We just happened to have a couple re-admins in a row. Toxic behavior at RfA is definitely a thing and worrying about re-RfAs contributes a bit to this problem. Jason Quinn (talk) 21:26, 15 December 2024 (UTC)[reply]
I don't see what the controversy is. Requesting the bit back at RfA has always been an option, and I applaud anyone who is willing to go through that again. There are very few people interested in going through RfA, so it is not overloaded and is far from a "waste of time." Anyone who believes it is a waste of their time is free to ignore it, just like everything else on Wikipedia. The only thing making these "reconfirmations" controversial is that a very loud minority is saying they are. WP:BROKE is something those people really should read and take to heart. — Jkudlick ⚓ (talk)21:57, 15 December 2024 (UTC)[reply]
I agree with a lot of the comments that have already been made. I don't think that this has become enough of a trend that we need to fix anything now, and I very much like Asilvering's comment that we should try to make RfA less of a special occasion. I've been having a kind of "meh" reaction to the complaints about wasting the community's time. I'm ambivalent about allowing snow closes. On the one hand, it might make things easier, but on the other hand, once a candidate decides that they want community feedback, we might as well let the community feed back. I also want to say that I'm against the bullet point about increasing the amount of time at BN: I think that would be counterproductive. --Tryptofish (talk) 21:59, 15 December 2024 (UTC)[reply]
I don't agree with turning the discussion at the bureaucrats' noticeboard from one that examines if the administrator resigned in order to avoid scrutiny into one where the general community discusses if it trusts the editor in question to regain administrative privileges. While it would be nice if every administrator had a perfect sense of the level of community trust that they hold, in practice I can understand administrators having doubts. I agree with Barkeep49's remarks on their talk page that we should be looking for lower costs ways for the admin to have a better idea of the degree of trust the community has in them. isaacl (talk) 00:46, 16 December 2024 (UTC)[reply]
Encouraging reconfirmation RFAs
At Wikipedia:Village pump (policy)#RfC: Voluntary RfA after resignation I commented that reconfirmation RFAs shouldn't be made mandatory, but they should be encouraged where the time since desysop and/or the last RFA has been lengthy. Barkeep49 suggested that this is something that would be worthy of discussion here (VPI) and I agree with that. If there is enthusiasm for this suggestion, an RFC to modify Wikipedia:Administrators#Restoration of the admin tools to include the encouragement can be drafted (unless this discussion shows the addition to be uncontroversial, in which case it can just be added). I do not propose to explicitly define "lengthy", that should be left entirely to the judgment of the administrator concerned, nor to make the statement stronger than "encouraged". Thryduulf (talk) 22:03, 15 December 2024 (UTC)[reply]
I definitely agree with the idea. I don't think an exact time period should be specified (as it isn't mandatory either way), but something in the ballpark of "several years" could be a good benchmark. Chaotic Enby (talk · contribs) 22:06, 15 December 2024 (UTC)[reply]
For the same reasons that editors are saying, above the section break, that this probably doesn't need to be fixed at this time, I see this, too, as something that probably does not need to be fixed. --Tryptofish (talk) 22:12, 15 December 2024 (UTC)[reply]
I have no problem with this proposal, nor would I attempt to define "lengthy" as it draws a relatively hard line where someone could complain that Former Administrator Example resigned the bit x+1 days ago and shouldn't be allowed to go through BN, or resigned x-1 days ago so shouldn't "waste the community's time." If we are to require an RfA after less time than is already prescribed at WP:ADMIN, that would require a separate RFC because it would be changing a policy and would absolutely be controversial. — Jkudlick ⚓ (talk)02:15, 16 December 2024 (UTC)[reply]
_-_La_Jeunesse_(1883)_(12387743075).png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
